Re: Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 8

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

> Date: Sun, 8 Jan 89 15:30:47 CST
> From: alarson@src.honeywell.com (Aaron Larson)
> 
> Presumably this would make (defconstant foo (list 'a)) an error.  

The intention was that the behavior would be "unspecified"; you don't
know whether the compile-time or load-time value would prevail, but it's
not a crash-and-burn situation.  See issue COMPILE-ENVIRONMENT-CONSISTENCY.
Perhaps we should say that values should be "equivalent" instead of 
"the same".

> Why is it
> necessary to permit an implementation to evaluate the constant form at both
> compile and load time?

Because, after debating this issue at great length, we weren't able to
come up with a consensus.  As it says in the rationale section, the
wording is intended to legitimize all of the variants. 

> Several references to "the same file"  Does this mean that the compiler can
> (or is required to) forget the info once the file has been compiled?

It can, but is not required to.  For instance, it would be a valid
implementation technique for COMPILE-FILE to fork a child process to
do all the work.

> Presumably if the compiler compiles a definition of FOOMAC, then loads a
> different version of FOOMAC (say from a different file) later compilations
> will use the LOADED version right?  I.e. there must be some precedence
> between databases maintained by the compiler and the interpreter if they
> are allowed to be separate.

This is a problem we are still working on.  Lately there has been a
drive to use environment objects as the database for the compiler; for
example, the CLOS spec appears to assume that something like this is
going on, and that the information in the environment overrides anything
in the ordinary run-time environment.  There are many unresolved issues
here, because CLtL says that environments need only contain information
for expanding local macros which have a clearly defined lexical scope.

>        DEFSTRUCT: ... The #S reader syntax may or may not be 
>        available at compile time.  
> 
> Can't this be resolved one way or the other?

I suppose we could say it "is an error" to try to use the #S syntax
at compile time, which is more or less the same thing.

> The descriptions of DEFCLASS, DEFGENERIC, and DEFMETHOD are significantly
> weeker than the specification of what they do we just received in the CLOS
> chapter 3 spec.

I have asked the CLOS people several times for assistance with this
issue, but they have not responded to my pleas.  What's in our
proposal is the best we could come up with from our understanding of
the issues involved.  I'm far from being a CLOS wizard myself and I
haven't had time to look over the new CLOS chapter 3 at all yet. 

The specification for DEFINE-CONDITION was derived from the sample
implementation Kent Pitman distributed many moons ago.

-Sandra
-------