Recognizing QUOTE deemed harmful to EVAL's laziness

[mike%acorn@oak.lcs.mit.edu]

    Date: Wed, 22 Jul 87 13:51:44 CDT
    From: reddy@b.cs.uiuc.edu (Uday S. Reddy)
    
    I too am quite perplexed by Drew's essay............

Amen.

    ....................  Since FOO can never be the normal form value
    of any expression (if FOO is bound, then its binding is the normal
    form and, if it is unbound, then it is an error) they print FOO and
    expect the user to understand it as (QUOTE FOO). 

I mostly agree with Uday's point. I'd like only to comment on the use of 
the term "normal form" in programming language analysis.

In Scheme or Lisp, you need a more powerful notion of Normal Form
than in a language without meta-language operations. Vanilla
expression rewriting cannot handle languages where the space of
values which cannot be rewritten by any rules (call them denotations,
values, etc) overlaps with those that can be. (call them expressions,
programs, etc.)  Context is needed to distinguish when rewriting
should continue and when it should halt.  Lisp-like languages with
quote have this property, in that an expression can evaluate or be
reduced to a value which is indistinguishable from an expression,
except that in context, it is not intended for re-evaluation, but as
an "answer".

(QUOTE FOO) denotes the value FOO, a symbol, not the expression FOO a
variable. No further evaluation is done on this value, no matter what
the context is. Hence, (QUOTE FOO) never has anything to do with any
value that the expression FOO (a variable) may have. In Scheme or
Lisp interpreters, this distinction between a symbol or S-expression
as a value, and as an expression is maintained by using applicative
(inner most) evaluation order. This avoids the problem of reexamining
expressions and thereby confusing a symbolic value with an expression
in the language. 

Of course all this goes out the window if you allow a program to 
call the interpreter,... i.e., EVAL.

...mike beckerle