Re: Issue: LOAD-TIME-EVAL (Version 6)

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

I have two problems with this proposal.  The first is a big one: there
a more situations in which code is processed than simply
interpretation and compilation.  It is not an either/or situation.  A
person here at the UofU, for example, has been working on a portable
type inference preprocessor.  It reads in code, decorates it with lots
of type declarations, and writes it out to another file which may then
either be loaded interpretively or compiled with COMPILE-FILE.  Under
this proposal, such a tool would essentially have to redefine
MAKE-LOAD-TIME-CONSTANT (a no-no) to always force evaluation to be
delayed, i.e.

    (defun make-load-time-constant (form env)
        `(make-load-time-constant ',form ',env))

That's why I believe that providing this functionality by defining it
as a special form is a superior alternative.

The other quibble is with the environment argument.  As I've already
pointed out to Moon, the environment object returned by &ENVIRONMENT,
as currently defined, may return an incomplete environment that
contains information only about MACROLET constructs in the surrounding
lexical environment.  I gather that this proposal depends on
&ENVIRONMENT being redefined to include information about whether or
not compilation is in progress, and that would be the only part of the
environment object that is used by MAKE-LOAD-TIME-CONSTANT, right?  (I
also understand that CLOS depends on maintaining some other
information in environment objects so I think a proposal to clarify
what they must really contain is in order.)

All things considered, I could live with this proposal, since it would
certainly not be any worse than the status quo.  On the other hand, I
would definitely prefer to either remove #, entirely or provide the
functionality as a special form.

-Sandra
-------