Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS

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

> Date: Fri, 20 May 88 15:09:45 EDT
> From: Rob.MacLachlan@WB1.CS.CMU.EDU
> 
> Like Jonl, I favor saying that forms like DEFMACRO are actually truly,
> honest to God evaluated by the compiler.  This could be done by an
> expansion that includes an EVAL-WHEN, but it should be required that all
> Common Lisp semantics of evaluation of that defining form should be present
> in the compiler environment after the implicit evaluation.
> 
> It could be a bit icky actually installing the DEFSTRUCT slot accessors,
> but this could be finessed by pretending that the slot accessors expand to
> DEFUNs outside of the EVAL-WHEN.

These two paragraphs seem mutually contradictory.  If you want to make
all of the defining macros implicitly EVAL-WHEN (EVAL COMPILE LOAD), like
the N random package functions, then you're going to get the defstruct
slot accessor functions defined at compile time, too.  If you want the
defining macros to make some things available at compile time and other
things not, I think you either have to use EVAL-WHEN in the expansion
or have the compiler treat every one of these guys like a special form.

Again, the proposal as written appears to be fairly close to current
practice.  Other than KCL, I don't know of any implementation that fully
evaluates DEFUN forms at compile time, and I don't know of any
implementation that doesn't do something special with DEFMACRO and
DEFVAR.  In some implementations, the compile-time side-effects of
DEFMACRO make the macro defined in exactly the same way as if the form
had been evaluated by the interpreter, and in others the macro
definition is stored someplace where the compiler can see it but the
interpreter can't.  Some people have made a fairly strong argument that
compilation side-effects should not affect the interpreter at all.

I think it would be nice to be able to definitely specify one way or the
other, either that the side-effects must be identical in the compiler to
what they are in the interpreter, or that the side effects must not be
visible to the interpreter at all.  However, I think the diversity of
opinion on this issue might prevent us from getting the rest of the
proposal through to the full committee, and I think it is *very*
important that we do that as soon as we can.  That is why the current
proposal explicitly leaves this behavior unspecified.  If we eventually
reach agreement to tighten it up one way or the other later on, there is
nothing to prevent us from presenting another proposal to amend this
one.  I just don't see that happening in the next few weeks.

-Sandra
-------