Re: 4.2

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

I'm having a hard time identifying exactly what changes you've made to
the language in this section since the draft I sent you earlier (all
of the TeX stuff makes this extremely difficult to read), but here's
an attempt to answer some of the questions I saw.  Some of the other
rewordings you did looked a little awkward to me, but I really want to
be able to look at a readable hardcopy of the whole section before
trying to make suggestions about that kind of thing.

> The term source code is used to refer to the {\word objects\/} constructed
> by
> {\function compile-file\/},
> and additional {\word objects\/} constructed by
> macroexpansion during {\function compile-file\/}.
>  
> %[rpg: I think the source code is whatever the representation is in
> %whatever a file is. I think this use of READ as a semantic crutch is
> %unnecessary.]

I disagree.  "Objects constructed by COMPILE-FILE" is not specific
enough and could be taken to refer to objects that COMPILE-FILE
constructs and uses internally during the process of compilation, such
as intermediate code or register mappings.  I think the original 
definition makes it clear what objects we're talking about.

Re the requirement that COMPILE-FILE uses READ.  This is indeed stated
explicitly in CLtL (on page 69) and also in the
EVAL-WHEN-NON-TOP-LEVEL proposal we voted in at the last meeting.
That inclusion was deliberate -- it's important to state somewhere
along the line that COMPILE-FILE uses the normal reader mechanisms --
and I would object very strongly to removing it.  I would object even
more strongly to removing it as an editorial decision without bringing
it up for a vote before X3J13 first.  (I don't know exactly what the
charter of the drafting committee is, but I thought the intent was
that you guys are supposed to turn the decisions made by X3J13 into
words in the standard, not ignore those decisions and write the
standard the way you think it should be.)

> %% Moving the following two bullets to 4.1 

I don't understand why, since these two items deal with actions that
must be performed at compile-time.  Where exactly in section 4.1 are
you planning to move them?


> %[rpg: There is a complicated issue: Can the compiler assume that the
> %resulting code in a compile-file situation will be run in the same
> %Lisp? The same implementation? The same computer?  The same type of
> %computer?

We've made a conscious decision in the compiler committee not to
address problems relating to cross-compilation.  Kent claims that it's
impossible to do a fully general cross-compiler, and in any case I
thought we'd be unlikely to resolve all the problems within a reasonable
timeframe.

> In the discussion that follows, the
> compiler can assume that when doing {\function compile-file\/},
> the resulting
> code will be loaded into a fresh copy of the same Lisp.

I would rather leave this out and have the standard remain silent on
this question.  I don't think it's particularly relevant to what's
being discussed in this section, anyway.

> Also, the compile time
> environment means definitions made in the file being
> compiled or definitions made in the Lisp running the compiler, either
> before calling 
> {\function compile-file\/} or inside {\tt (eval-when compile ...)\/} 
> in the file.

I don't think we've actually stated anywhere in our proposals that
this must be the case.  I don't think we've voted on anything that
would prohbit you from implementing COMPILE-FILE by having it spawn a
fresh process that contains only the standard Lisp environment and
nothing else that happens to be present in the Lisp in which the user
invoked the COMPILE-FILE function.  The compiler committee initially
wasted a lot of time discussing this issue and we eventually decided
to punt on the question and move on to more productive things.
Anyway, once again I think it would be better to remain mute on this
question than to put something in the standard that hasn't actually
been approved by X3J13.  At least at one time this was a controversial
issue and I don't think it would be right to sneak it in as an
editorial change.

> A reference to the compiler
> means the {\function compile\/} function
> and implicit compilation, for which the compile time environment and the
> run time environment are two different states of the same Lisp at different
> times. 

I'm not sure what point this sentence is trying to make.  A reference
to the compiler can also mean the function COMPILE-FILE, but the
second part of it is true only of COMPILE and implicit compilation.
I've kind of gotten used to Kent's terminology of using "file
compiler" and "run-time compiler" to distinguish the two different
kinds of compilation in contexts where it makes a difference, and
using "compiler" as a term that includes both kinds of compilation.
Certainly in the discussion in question here, "compiler" includes both
kinds.

> %[rpg: the interpreter can assume the same thing, right? That is, a
> %valid Common Lisp has be one in all code is compile-filed by a
> %separate program and loaded and executed in the apparent Common Lisp
> %image.]

I don't understand this remark.  Yes, all of these things also apply
to the evaluator.  The difference is that the evaluator is effectively
allowed to do both compilation and execution at the same time, so the
time at which things are allowed to happen is not so important.  This
whole section is trying to address the question of what things happen
during compilation and what things happen during execution, when those
two times aren't necessarily the same.

> % The following paragraph from issue COMPILE-ENVIRONMENT-CONSISTENCY
> %    seems likely to change:
>  
> \itemitem{\bull}  
> The compiler can assume that type definitions made with 
> {\function deftype\/}
>   or 
> {\function defstruct\/} in the compile time environment will retain the same 
>   definition in the run time environment.  It can also assume that
>   a class defined by 
> {\function defclass\/} in the compile time environment will
>   be defined in the run time environment in such a way as to have
>   the same {\word superclasses\/} and compatible metaclass.  
> %[rpg: compatible metaclass?]

I'm confused.  Where did this language come from?  It's not the
current language in the COMPILE-ENVIRONMENT-CONSISTENCY proposal, and
it's not the language of Gregor's proposed amendment either.  Does
this represent the new position of the CLOS people on this issue (that
I haven't been told about)?
 
-Sandra
-------