Re: Issue: EVAL-DEFEATS-LINKER

[willc%tekchips.tek.com@RELAY.CS.NET]

This is my response to a message from Scott Fahlman.

> This proposal seems very odd to me.

Cultural differences account for this:

    I think ordinary programs (which don't call EVAL or any of its subspecies) 
    should be linked selectively with no special effort.  This is what people
    do every day with other programming languages, including Scheme.  I
    couldn't care less about programs that explicitly call EVAL or its
    subspecies, because Real Programmers don't call EVAL.

    Scott wants programs that call EVAL or its subspecies, which he and
    his culture consider to be normal programs, to be linked selectively.
    This requires the user to name all the functions that might be involved
    in a call to EVAL.  He couldn't care less about programs that don't call
    EVAL or its subspecies, because Real Programmers call EVAL.

> 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.

The second sentence is correct only if EVAL or one of its subspecies is called
explicitly, the language is poorly designed, or the implementation is not
structured for selective linking.  I don't think programs that call EVAL
are worth worrying about, and I'm trying to patch the language design so
future implementatations can be designed for selective linking.  Note that
READ without EVAL would cause no problems for selective linking in a well-
designed implementation if it weren't for the language problems I have
identified.

> 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

My summary of this is that Scott is proposing that the semantics of EVAL
be left unspecified, and that it is ok to do this because EVAL is part of
the programming environment, not part of the language.  His proposal
wouldn't work unless we did the same for EVAL's subspecies like
SYMBOL-VALUE and SYMBOL-FUNCTION, so I have to assume he wants their
semantics to be left unspecified as well.

Considered by itself, this change in the status of EVAL and its subspecies
would be catastrophic, because essential functions like FUNCALL and APPLY
are defined in terms of EVAL or its subspecies.  If we change FUNCALL and
APPLY as I propose, and go further to fix everything else that depends on
EVAL and its subspecies, then I would be very sympathetic to the idea of
dropping EVAL, SYMBOL-VALUE, and SYMBOL-FUNCTION and their ilk from the
supported language.  I doubt that Scott really wants to go that far.

================================================================

I am sympathetic to David Moon's suggestion that #. and #, could be
left out of the proposal, since programs that want to be linked
selectively can just define #. and #, to be something innocuous.

-- Will