CSC302 2005S, Class 7: The Scheme Report

Admin:
* Missing: Rosenbluh, Brantley, French, Petersen
* Late: Yilma, Guha, Kasidhi
* Bagels is available near Shireman.  Juice is available near Nyombayire.  Enjoy.  (You need not feel obligated to take either or to enjoy.)
  * Sam baked a gross of bagels on Saturday.  It's evident that he's Rosenbluh's advisor.
* Read chapter 6 for Wednesday.
  * You may also want to start chapter 7.
* Today's questions were optional, since I didn't distribute the report.
  * Does anyone still need a printed copy? (3 or 4)
  * I'll accept multiple kinds of questions (clarification and discussion).  Let me know what kind you're asking.
  * From now on, I indicate "check" by putting your name in the list of questions.  If you don't see your name, check with me.
  * Questions should be grammatically correct and, when appropriate, cite the page of the reading.

Overview:
* About R5RS and why we're reading it.
* The lambda calculus.
* Object lifetimes and garbage collection.
* Errors.
* Tail recursion.
* Continuations.
* Other topics.

What is R5RS?
* A specification of the Scheme programming language
* Intended to ensure a fairly common base for Scheme
* Not the same as the ANSI standard

Why are we studying the Scheme report in 302?
* As part of the "how many ways can you approach the functional paradigm" track.
* To permit us to compare Scheme to other languages.
* How does one describe a programming language?
  * Relatively concise report.
  * Relatively careful.
  * Different levels.
* Bookend your career
* Example of denotational semantics
* Side note: Josh's uncle help edit the report (not as a central editor, but ...)

What is the structure of the Scheme report?
* Chapters 1-5 define multiple functions
* Chapter 1: Language in a nutshell: Casual definitions of syntax, semantics, and approach
* Chapter 2: Lexical conventions, mostly informally, both individual tokens and the structure of expressions 
* Chapter 3: Basic and important concepts in slightly more depth: Variables, type checking, string representation, tail recursion
* Chapter 4: Expressions and Macros: Syntax, Legality, Evaluation paradigm.  Still comparatively informal.
* Chapter 5: What is a program?  Some syntax, some semantics.  Again, relatively informal.

Chapter 1: Introduce the language
Chapter 2-5: Explain the language in more depth (enough that someone could use the language)
Chapter 6: Reference on key procedures
Chapter 7: Formal syntax and semantics

Who is the audience of the Scheme report?
* People implementing Scheme - lots of aside on implementation; chapter 7 is certainly on implementation
* The people who have already implemented lots of different dialects of Scheme, with a hope that they unify
* Early chapters: Thoughtful programmers interested in learning (about) a new language

The lambda calculus
* In the 1920's, a group of mathematicians decided to attempt to represent "what mathematicians do" - the field of Formal logic
  * Alonzo Church designed "the lambda calculus" as a way to model what functions are
  * Notation for representing functions
  * Formal meaning assigned to the notation
  * Ways of reasoning
  * Important things for us
    * (lambda (x) body) - A function of parameter x defined by body
    * Binding rules: When we see multiple copies of the same "variable", which is which?
      (lambda (x) ((lambda (x) x) x))
    * Evaluation rules: What does it mean to apply a function to an argument?
    	((lambda (x) body) expression)
    * Interesting theoretical outcomes
      * What is an answer? (The value of a function?)
      * Are there functions that have no result?
      * Innermost and outermost evaluation lead to the same result if there is a result.
* Obligatory story
  * Sam adivsor: O'Donnell
  * O'Donnell's advisor: Constable
  * Constable's advisor: Kleene
  * Kleene's advisor: Church
  * Church's advisor: Oswald Veblen, UofC '08 or so

Object lifetimes and garbage collection.
* "Objects are never deleted"
* The runtime system reclaims them if it can "prove" that they'll never be used again
* Programmers never delete objects
* How does the system know something will never be used again?
  * Limited scope view: If there's no way to refer to it (even indirectly), you won't use it again.
  (define x (list 'a 'b 'c))
  (set! x (list 'will 'you 'use 'this?))
* References are complex
  * The "environment" of lots of code gets saved
(let (x 10)
  (lambda (y) ...))
* Happens in continuations, also

Errors.
* Certain errors have forced consequences; others don't.  Why not?
  * Some errors are impossible to detect.  It's hard to say "You must do this when this error happens if you can't detect the error."
  * Some errors are hard to detect.  By allowing the implementor to "ignore" the error (or do whatever is most convenient) you 
    * Faster code
    * Happier implementers

* Some procedures don't have a specified return value.
  * (write ...)
  * (xxx! ...)
  * Not functions in the traditional sense;
  * Intended imperatively, therefore should be used imperatively.

* Why do some languages return values from set and write and everything else?
  * Different design perspectives.
Tail recursion.
Continuations.
Other topics.

What is R5RS?