EVAL

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

    Why is it that EVAL returns the value in the current DYNAMIC
    environment, rather than the lexical environment?  Or perhaps the most
    recent binding (lexical unless a variable is special)?  Or if this is
    necessary for some reason, why isn't there another function, say,
    LEXICAL-EVAL that does this?  It seems rather strange to have a mainly
    lexically scoped language with no facility for lexical evaluation.

EVAL cannot easily be defined to work in the lexical environment in
which it appears because that lexical environment is not around at
runtime, when the argument to EVAL arrives and the evaluation occurs.
In any event, it would eliminate many of the benefits of lexical scoping
to provide a loophole through which arbitrary forms might be smuggled
into a lexical environment at runtime.  For example, certain
optimization are now possible because the compiler can examine all
possible references to a lexically-bound variable by scanning the
lexical block in which it is bound; thsi would go away in the presence
of your LEXICAL-EVAL.

So the language specifies that EVAL operates within the current dynamic
environment and the null lexical environment, and it does not provide a
way to pass a non-null lexical environment to EVAL.

For debugging, it is useful to be able to access lexical variables by
name, but this falls outside of the language proper.  It does not need
to be portable and it does not need to work in code that has been
altered beyond recognition by the compiler.

I must have answered this question a hundred times, both on this mailing
list and elsewhere.  We'd better put a "rationale" statement intot he
next version of the manual, since people seem to find this more
confusing than anything else (except maybe packages and case conversion).

-- Scott