EVAL and friends

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

Guy,

Now that I've written a lexical interpreter for Slisp, I am somewhat
mystified by the decisions you made in defining the various flavors of
EVAL.  It seems to me that there are three things needed:

1. Eval a form in the current lexical context.  This is used a lot, and
there is no way that I can see to do it in user-level Common Lisp, since
no way is provided to get your hands on whatever it is that you pass to
*EVAL as the environment stuff.  I've defined a %EVAL that does this (it
uses %venv% and friends as specials without rebinding them).  I find
that almost all of the places where I was previously using EVAL now use
%EVAL, which makes these things non-portable.

2. Eval a form in the null lexical environment.  Needed very rarely, but
needed.  EVAL currently does this.

3. Eval a form in some user-supllied lexical environment.  This is what
*EVAL does.  It seems to me that *EVAL is not a legitimate user-level
function and ought to be made a system-internal form, since the form of
the environment arguments are left up to the implementation.  This is
needed in the debugger and a couple of other places, but is inherently
unportable.  (I assume that we do not want to take the step of trying to
agree on the exact format of the environment across all
implementations.)

It seems to me that a name-rotation would clean things up a good deal.
Case 1, eval in the current environment, would just be EVAL.  Case 2
would get a name such as EVAL-IN-NULL-ENVIRONMENT or some such.  (It
could be *EVAL, but I find the random use of *'s to be confusing.)  Case
3 could then inherit the name %EVAL or SI:%EVAL, and could disappear
from the white pages altogether.  Every implementation will need to
provide this function internally, but it is not a portable user-level
function since it takes implementation-dependent arguments.

Macroexpand and other forms that currently take these environment args
should get a parallel treatment.

Perhaps case 3 is too important to flush from the white pages.  I
suppose we could provide a new function CURRENT-LEXICAL-ENVIRONMENT and
a new (defstruct) data type called a LEXICAL-ENVIRONMENT-OBJECT or some
such.  The former returns one of the latter, and at any time thereafter
you can pass this to *EVAL and have it used as the environment.  This
encapsulation keeps us from having to define the internal structure of
the environment.  It would not be efficient, but would give us a way of
doing the current *EVAL without appeal to secret rituals.  I have not
really thought through all the implications of this, and the idea may be
more confusing than useful.  If we don't absolutely need this
functionality in the white pages, flushing it would be a good thing.

-- Scott