[Openmcl-devel] STEP functions

[Gary Byers]

On Sat, 9 Jan 2010, Ron Garret wrote:

> Since the topic has been raised, why does cheap-eval-in-environment
> still exist then?

For those who don't know, a function named
CCL::CHEAP-EVAL-IN-ENVIRONMENT basically implements the "simple" parts
of EVAL, where "simple" is roughly "things that don't involve variable
or function bindings, BLOCK, or TAGBODY".  Any form that's not simple
is evaluated by making a function out of `(lambda () ,form) and
calling that function; at one point, a global variable
(CCL:*COMPILE-DEFINITIONS*, IIRC) controlled whether functions created
by the evaluator in this and other cases were compiled or intepreted.
At some point (it might have been closer to 7 or 8 years ago ...),
support for interpreted functions was removed.

It'd probably work (for some value of "work") for it to always compile;
but there are practical arguments against it. EVAL is defined in terms
of CHEAP-EVAL-IN-ENVIRONMENT, and there are at least some incidental
uses of EVAL (to implement things like LOAD-TIME-VALUE) that might
occur in the loading sequence before the compiler is loaded.  EVAL
might also be used in the assembler (as an expression evaluator).  I
don't know if the assembly-level code generated by the compiler contains
expressions that need to be evaluated, but if it did the recursion
would have to stop somewhere.

It's probably also true that the simple things that C-E-I-E handles -
mostly function calls, free variable reference and assignment - can
be handled more "cheaply" if the compiler's not involved.  (I don't
know how much more on average or how important this is.)

The fact that the compiler's sometimes involved and sometimes isn't
means (among other things) that things entered into the REPL sometimes
generate warnings and sometimes don't.  The fact that different evaluation
mechanisms have different behaviors in this respect is the closest thing
that I can see to a reason to eliminate one of those mechanisms, but I'm
not sure how strong that reason is.



>  And could this be used to bootstrap a STEP function?

You could make CHEAP-EVAL-IN-ENVIRONMENT obey something like the
APPLYHOOK/EVALHOOK interface that's typically used to control stepping,
and that would give you the ability to step through the simple things
that CHEAP-EVAL-IN-ENVIRONMENT handles.  (Since C-E-I-E basically 
considers many CL constructs to be above its pay grade, that probably
doesn't allow you step through too much.)

You could reinstate support for interpreted functions, but that'd
basically return things to the state that they were in ... however
many years ago it was that that support was removed.  You might be
able to add some functionality to the stepper that'd make that more
palatable, but I think that there are severe limitations to approaches
based on debugging interpreted code (in an implementation where you're
otherwise always running compiled code.)