Issue: EVAL-DEFEATS-LINKER

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

This proposal seems very odd to me.

It is certainly desirable for a Common Lisp implementation to have some
way to create a core image for application delivery that contains only
as much code as that application needs, and not all the rest of Common
Lisp and the associated development environment.  I have argued that
this approach to application delivery is much better than trying to
create some small delivery-oriented subset of Common Lisp: it is better
to keep those functions that you actually use and jettison the rest than
to try to guess in advance what subset would be appropriate for a whole
class of appliction.

A normal garbage collection will keep alive all of the functions that
are actually needed by a given application program, either directly or
indirectly.  Unfortunately, it will also keep alive every other function
that is globally named by a symbol, even if that symbol is not mentioned
in the application code.  Such functions are still "accessible" if there
is a read/eval present, since the user could ask for them by name, so
the garbage collector is not allowed to eliminate them.

We could get rid of these named functions if, by examining all the
application code, we could prove any of the following:

1. The symbol is not mentioned in the application and there is no way to
smuggle it into the system at runtime via calls to read, intern, etc.

2. The function is not called anywhere, and the symbol, though it may be
present, is not converted into a function anywhere.  Clinger's proposal
is to make this proof easier by eliminating a large class of implict
symbol-to-function conversions.

3. The function, though it may be present, is not called and is nowhere
passed to EVAL, APPLY, or FUNCALL.

That's one approach to eliminating the unneeded parts of Common Lisp.  A
different approach is is to simply ask the user to declare that the
application does not contain a full Common Lisp interpreter, if that is
his intent.  For example, an implementation might provide a facility
called COMPRESS-FOR-DELIVERY that retains a user-specified set of root
functions and everything that they call (transitively), but that flushes
all other functions that are normally found in a Common Lisp.

If such an application happens to have an EVAL lurking within, and if
the the user somehow passes (Y-OR-N-P "Foo") to it, he might find that
Y-OR-N-P is simply undefined.  Sorry, but this is a desk calculator, not
a full Common Lisp interpreter.

It seems to me that the latter approach is by far the more interesting
and useful one.  It also seems to me that this is an environment issue
and not something that this committee needs to worry about.  I see no
significant portability issue here.  In the compressed system, EVAL
doesn't mean quite what it did before, but nobody is claiming that this
desk calculator is a legal common lisp.  Exactly what COMPRESS retains
will depend on the internal details of each implementation, so there is
no point in trying to standardize this.

-- Scott