Issue: EVAL-DEFEATS-LINKER

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

    > This proposal seems very odd to me.

    Cultural differences account for this:

Yeah, I guess so.  I actually don't object to your proposal.  I've got
no objection to your kind of "selective linking with no special effort"
if a system wants to supply it.  I think that a system geared for
application delivery wants to have the kind of user-specified
compression I described in the previous note, but if some compression
can happen automatically, so much the better.  If the price for this is
flushing the coercion in APPLY and FUNCALL, that just gives me another
reason to favor FUNCTION-TYPE:STRICT-REDEFINITION, which I support for
other reasons anyway.  Like Moon, I dislike the change to #. and #, ,
but I guess that's not a big issue here.

    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.

Well, not really.  It's another matter of culture, I guess, but I think
of this as leaving the semantics of EVAL alone; EVAL still treats a
symbol defined as a function just as before.  What changes is the set of
symbols that happen to have functional definitions at runtime.  Think of
it as coding in a Common Lisp subset, but you don't choose the subset
until the program is done and you examine what functions you actually used.

I suppose that flushing something like ATANH at compression time could
be viewed as changing the semantics of EVAL, and I suppose you could say
that this is disastrous because EVAL is used to define other things, but
I don't really see this as a useful way to look at the world.  If you
take this view, doesn't it also change EVAL (in a disastrous way) when
you define some new function?

-- Scott