More on LISP:

     - S-expressions:  These include atoms, things of the form
       (expr1.expr2) (i.e. binary trees with S-expression leaves), and
       NIL (to denote the empty list.


     - M-expressions: They include the following:

       1) S-expressions (the constant values of M-expressions)	  

       2) fn[ m_expr_1; ... ;m_expr_n], where fn is an S-function.  This
	  type of M-expression represents the familiar math function
	  notation fn(m_expr_1, ... , m_expr_n).  The LISP people used
	  [;] notation because it was simpler to implement with
	  punchcards.  Examples of common S-functions included cons,
	  car, cdr, plus (equivalent to modern +).

     - They provided a scheme for encoding M-expressions as
       S-expressions.  The following translations were made:

       fn --> FN 
		 (translate functions and constant symbols into atoms)
       2 --> 2

       s_expr --> (QUOTE s-expr)   (more on QUOTE below)

       fn[expr1; ... ; exprn] --> the list (FN T(expr1) ... T(exprn))
		 which is an abbreviation of 
		 (FN . (T(expr1) . ... (T(exprn) . NIL) ... ))
		 where T(expr1) is the encoding of expr1 as an
		 S-expression.

		 This way, every part of the structure is an
		 S-expression in a binary tree form, which is an
		 S-expression itself.


     - They introduced the function eval to do something with all this
       syntax:
       
       eval[Sexpr; env] = the S-expression that is the value of the
			  M-expression encoded into S-expr where env
			  gives the local value meanings to the selected
			  atoms. 

       apply[fn; arg1; ... ] was the universal function for LISP, but
       nowadays it is eval

     - Ambiguity of Notation:  The question arises whether (+ 1 2)
       evaluates to 3 or (list + 1 2).  That is, it isn't clear if this
       S-expression form is a binary tree or a program to be run. So,
       they cooked up the QUOTE system to differentiate between the two,
       where

       eval[(QUOTE S-expr); ...] = S-expr


     - LISP as a functional programming language: LISP has many
       properties of functional programming languages, but not all.
       Some notables include:

       1) "Referential Transparency":  You can understand the value of a
          subexpression by itself.  (A property of LISP Common to FPLs)

       2) Functions as first-class values (A property of LISP Common to FPLs)

       3) Idempotence of evaluation (i.e. value of the value is the
          value) is NOT a property of LISP (but it is in other FPLs like
          ML and Haskell)

Some Notes on Step 3 of the Project (due Friday):

     - As it currently is implemented, we start the calculation from
       scratch every time a new precision is given.  We can get around
       this by trying another approach.  Now, we will treat exact reals
       as infinite numerals (that is, we assume that every number is
       irrational).  We can then define a process that can compute
       successive numbers of the infinite sequence of increasing
       precision values, and then specify how many numbers to go down
       the line.

     - We run into a complication:  You can't define a process to
       compute a list sequence of zeroes as follows:

       (define zerolist
	   (cons 0 zerolist)
	)

       However you can define an object called a stream (see DEMO) that
       assumes functions used in definitions are yet to be run,
       consequently obscuring the lack of a proper existing definition
       for it.  Then, you can define the zerolist generator as follows:

       (define zerostream
	   (cons_stream 0 zerostream)
	)

       Then, first_n_stream runs the zerostream succession n times,
       producing lists of n zeroes, as desired.  (Also see the
       incremented list example in the DEMO).

       So, we can define the structure of an infinite sequence (treated
       as a list here) and then produce as much as needed.  So, for the
       PAC, we can define an evaluation as a stream, and get as much
       precision out as you want.