proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

I am highly opposed to your whole approach here.  I know KMP doesn't
agree with me, so this is just my personal opinion.  Let me see if I can
explain without getting long-winded.  I've deleted about half of what I
started to say, which was really irrelevant.

You could simply have made the mechanism underlying #, available.
Instead, you chose to design a new mechanism that works a different way.
This requires either having two ways to do load-time evaluation, or
incompatibly changing #, to work the new way.  You chose the latter
course.  This makes #, incompatible both with #. and with its previous
definition.

The new mechanism has all sorts of problems with multiple evaluation
that #, did not have.  The semantics of #, were very clear, if somewhat
off the wall.

The new mechanism tempts you to introduce a new concept of non-read-only
constants, since now you have a place to put options.  This further
complicates the multiple evaluation issue by raising the issue of
side-effects and object sharing.  It also requires a complicated rule
about when the compiler can collapse apparently equal constants.  It's
also harder to implement than you think; any implementation that
formerly treated all constants as read-only now needs a way to label
each constant as read-only or writable.

The rationale claims that replacing #, with LOAD-TIME-VALUE simplifies
the description of Common Lisp, but this is clearly false.  Even a
rigorous description of #, would be much less verbose than this proposal.

So what makes #, simpler than LOAD-TIME-VALUE?  Since #, can only be used
inside quoted constants, we don't need any new rules about how the result
can be used.  Since #, is a feature of LOAD rather than of EVAL, we don't
need any new rules about what happens if you evaluate it twice.  Since
#, is a feature of LOAD rather than of EVAL, there is no issue of
semantic incompatibility between the compiler and the interpreter.

How to make the mechanism underlying #, available?  This would be a
function that receives a form and returns an object (I'd use the term
"magic cookie" if I didn't hate it) which can be placed inside a quoted
constant; by the time the program is loaded, that position in the quoted
constant will contain the result of evaluating the form in the null
lexical environment.  It is only useful to call this function from
macros.  This function needs a way to tell whether a COMPILE-FILE is in
progress or not (as does CLOS); I hope that the compiler committee is
going to propose that the environment argument to macros can be used for
this purpose.  Symbolics Genera currently uses a special variable to
convey this information, which has all the bugs that dynamic scoping
always has.