1. You're writing a Lisp interpreter very much like the early implementors of Lisp did, about 45 years ago.
2. This is foundational work that led to the development of today's compilers and interpreters.
3. And most interestingly, the way interpreters are written today is fundamentally the same as how they were written way back then.

       ; This is an "x" version of Lisp's read-eval-print loop.  When the function
       ; read-xeval-print-loop is run, it will interactively input expr's from
       ; the terminal and hand them over to xeval.  Note that memory is defined as
       ; a prog var, that is sent automatically as a parameter to xeval.
       ;
       (defun read-xeval-print-loop ()
         (prog (memory result)
           (setq memory '(nil))
           loop
               (princ "X>")
               (setq result (xeval (read) memory))
               (princ (car result))
               (setq memory (cadr result))
               (terpri)(terpri)
               (go loop)
         )
       )
       

1. Notice that it's grossly imperative, with the use of setq's and goto's.
   1. The use of imperative constructs is limited to the top-level loop; the interpreter itself, i.e., the xeval function, is entirely functional in its behavior.
   2. In particular, xeval does all of its work through parameter passing and value returning, without using any global variables.
2. Notice that the return value of xeval is a pair of the form

   (computed-value-of-expr possibly-updated-memory)

3. By providing the memory as an explicit input parameter and returning it as part of the return value, xeval does not require a global store, in contrast to the normal Lisp eval.

1. The good-news/bad-news situation with Lisp is that due to weak typing, there is no explicit declaration of the memory structure anywhere in the template.
2. The good news is that weak typing allows high flexibility in how data structures are manipulated.
3. The bad news is that in order to determine what the structure of data is, one has to examine the program code closely.
4. In the case of Assignment 6, an important clue for how memory is structured is in memory dump dump shown in the file xeval-test-demo.

       ( name value )
       

1. A variable binding is a pair of the form:

          ( var-name data-value )
          

2. A function binding is a triple of the form:

          ( function-name formal-parms function-body )
          

1. This is a much simpler and more abstract way of doing things than in the EJay interpreter of Assignment 4.
2. There we had to define separate extensions of SymbolTableEntry, do casting when necessary, and mess around with a lot of strongly-typed structure.
3. Here the difference between VariableEntry versus FunctionEntry is just how many elements there are in the list representation of each.
4. Further, we are using the simple list-style bindings to represent both environment information (symbol table) and data store information (memory).
5. E.g., the binding '(x 4) can be looked up for x as in a symbol table, and evaluated to 4 as in a memory.

1. Variable bindings are created and modified by (xsetq x v) as follows:
   1. If there is no existing binding for x on the memory, add the new binding (x v) to the end of the memory.
   2. If there is an existing binding for x on the memory, change the value of the binding to v.
2. Function bindings are created and modified by (xdefun f parms body) in precisely the same way as variable bindings with setq; namely
   1. If there is no existing binding for f on the memory, add the new binding (f parms body) to the end of the memory, where parms is a list of formal parameters of the form ( p₁ ... p_n ).
   2. If there is an existing binding for f in memory, change the value of the binding to parms body.
3. Function call bindings (a.k.a., activation records) are created and removed by function calls of the form (f a₁ ... a_n)
   1. Before the function body is evaluated, a new binding is created for each a_i, of the form

             ( pi ai )
             

      and these bindings are added to the end of the memory.
   2. After the function body has been evaluated, the activation bindings are removed, by restoring the memory to its state before the bindings were added.

1. Whenever a new binding is made, it is added to the end of the memory.
2. Whenever a binding is searched for, the search starts from the end on which the most recent addition was made.
3. And note well the phrase from above: "... by restoring the memory to its state before the bindings were added".
   1. This means that any new bindings made by setq or defun during the course of function body evaluation are non-permanent.
   2. I.e., such bindings effectively become part of the activation record, and are removed after function evaluation has completed.

1. However, whatever specific implementation of memory you use, you must get the same results for the output values as in xeval-test-demo.
2. That is, your memory dump can look different than mine, but the value results must be the same.

1. What we're doing here is co-mingling the static pool and stack into a single piece of memory.
2. When global variables are bound at the top-level of the interpreter, they go in the top part of memory, which is effectively the static pool.
3. When functions are called, activation records are pushed onto the stack, with the top of stack being at the bottom of the current static pool.
4. These two aspects of memory management are the same as in Common Lisp and the EJay interpreter of Assignment 4.
5. What's different here compared to Common Lisp (and EJay) are the following points:
   1. When new bindings are made inside of a function, they go in the function's activation record, not in the static pool.
   2. When we look for the current value of a variable, we don't look separately in the stack then in the static pool, but instead just search all the way up the stack, which ends in the static pool.
6. The reason we're doing things this way that it's the simplest form of memory, and allows us to treat the stack and static pool as one uniform structure.
7. We'll discuss the ramifications of this simplified memory model next week.