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

["AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>]

It's good to some of these things written down.  Here are my comments
so far...

I think the issue name is a bit too general--how about
COMPILE-FILE-OF-DEFINING-MACROS, since it just talks about
DEFxxx forms, with the "top-level" assumed.

If we don't want to address inter-file dependencies in this issue,
we should say so explicitly.

Although this is an issue that comes with PROCLAIM, it's probably
worthwhile mentioning that when COMPILE-FILE sees a DEFUN, it may
decide to keep the body of the function around due to INLINE
proclamations.  VAX LISP requires INLINE proclamations to come
before the corresponding DEFUNs, because we don't want to keep around
all the source code ever seen just in case an INLINE proclamation/declaration
might come much later.

  "If the initial value form [of a DEFCONSTANT] is a constant, an
   implementation may also choose to evaluate it at compile time for
   the purposes of constant-folding."
Firstly, if the value is a constant, it may be evaluated at any time--
so this sentence doesn't say much.  [Or is the referent of "it" the
DEFCONSTANT expression?]  Secondly, I think it's more important to state
what an implementation -cannot- do, much as was stated for DEFVAR.
I think of DEFCONSTANT and DEFPARAMETER being very similar, except that
constants can't be set or bound.  I don't see why that would suddenly
allow the compiler to evaluate the inital value form at compile time.
So we should say that the initial value form must not be evaluated at
compile time.

For DEFSETF and DEFINE-SETF-METHOD, add the comment (as is included
for DEFMACRO) that the expansion needn't be evaluable at compile time.

Question: must the expansion of a DEFTYPE be a legitimate type at compile
time?

			---Walter
------