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

[David N Gray <Gray@DSG.csc.ti.com>]

> No, of course not.  I'm saying that #, is a feature of the reader that
> needs to cause the loader to do something appropriate with it.  #, never
> affects the evaluator, EVAL and COMPILE never see anything different when
> #, is used than they would see normally.

I was forgetting that in the old scenario, in evaluated code, the
expression following #, is executed by the reader instead of the
evaluator.  I guess the basic issue is:  if you generate one of these
load-time values in a macro expansion within the evaluator, should
the expression get evaluated as part of the macro expansion, or should
it be done directly by the evaluator?  Certainly tying the evaluation to
the macro expansion simplifies things greatly since the question of how
many times it gets evaluated is the same as the question of how many
times the macro gets expanded.  Maybe we could get the best of both
proposals by saying that LOAD-TIME-VALUE is a macro instead of a special
form, and it is defined something like this:

(DEFMACRO LOAD-TIME-VALUE (EXP)
  (IF (compiling-p)
      `(some-special-thing-only-the-compiler-cares-about ',EXP)
    `(QUOTE ,(EVAL EXP))))

As for the assumption that a QUOTE form containing a "magic cookie" passes
through the compiler just like any other QUOTE form, that unfortunately is
not quite true.  In our implementation the compiler actually has to scan
QUOTE forms looking to see if it contains a "magic cookie" for two
reasons:  to suppress optimizations based on the value of the constant,
and to prevent merging EQUAL forms that use load-time evaluation.  That's
why I think this approach is ugly -- it uses the syntax of a constant for
something that isn't really a constant.