Compiler section (4.2)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Indented text is an excerpt from the document being discussed.
I didn't want to include the whole thing in my reply.  I hope
this is enough context to locate the points I'm referrring to.

  % This paragraph should really conclude with a stronger statement that
  % conforming programs must be structured so they will work if implicit
  % compilation does take place, but CLtL doesn't come right out and say
  % that, and we have never voted on any issue to say that either.

I see no reason not to say that.  I think CLtL was intended to imply it,
so I don't see any reason why the drafting committee can't decide to
say it outright.  This means only a little more than that a conforming
program can't depend on just when macroexpansion takes place.

  - The compiler must capture declarations to determine whether
    variable bindings and references appearing lexically within the
    code being compiled are to be treated as lexical or special.  The
    compiler must treat any binding of a variable that has not been
    declared or proclaimed to be SPECIAL as a lexical binding.
   
  - The compiler must process EVAL-WHEN forms that appear lexically within
    the program being compiled.  Effectively, the compiler must replace
    the EVAL-WHEN form with either a PROGN containing the body forms, or
    a constant NIL.
 
Sandra didn't like it when I pointed out that the above two points are
requirements on both the interpreter and the compiler (as of the latest
compiler issues, in the case of EVAL-WHEN) and therefore don't belong
in this section.  If 4.1 is the semantics of execution of programs in
general, while 4.2 is the things that are peculiar to compilation,
then they belong in 4.1.

She didn't like it, but didn't convince me I was wrong.

    [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?
    I suggest that we say that the semantics we discuss presumes that the
    compiler can assume that when doing compile-file that the resulting
    code will be loaded into a fresh copy of the same Lisp.]
     
I think that is reasonable.  Implementations of compile-file can work in
other cases too, if they feel like it, but this is the only case
specified by the standard.  I think trying to define precisely what
"the same" means is likely to run into problems, I'd suggest leaving it
with rpg's wording and not trying to be more precise.

However we have to be careful not to rule out the common technique of
compiling a multifile program by compiling the first file, loading the
result, compiling the second file, loading it, etc.  It would be a shame
if conformance required rebooting the Lisp between each compilation.

    [rpg: the interpreter can assume the same thing, right? 

ANYTHING the compiler can assume the interpreter can also assume, since
there is nothing in Common Lisp that mandates any semantic differences
between the compiler and the interpreter.  Some implementations only
have one or the other.

    - COMPILE-FILE may assume that, in the absence of NOTINLINE
      declarations, a call within the file being compiled to a named
      function which is defined in that file refers to that function.
      (This permits "block compilation" of files.)  The behavior of
      the program is unspecified if functions are redefined individually 
      at run time.
      
    [rpg: the interpreter can assume the same thing, right?]

I don't think so, or even known what it would mean, because this is a
statement about COMPILE-FILE, not about the compiler.  Maybe LOAD of
a source file may assume ....?

    [rpg: This is a little curious. Is this talking only about this sort of case:....

Well, this whole section is unclear when it talks about the compile time
environment as to whether it means definitions made in the file being
compiled or definitions made in the Lisp running the compiler, either
before calling COMPILE-FILE or inside EVAL-WHEN COMPILE in the file.
I think it means both.  Of course these things when they say "the compiler"
rather than "COMPILE-FILE" also are talking about the 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.  Maybe Sandra should clarify?

  * If the form is an EVAL-WHEN form, it is handled according to
    the following table:

The formatting of this table is completely destroyed, the headings do
not line up with the columns.  To get a narrow enough table, maybe the
columns will have to be labelled with numbers and the headings given
in a caption.

  [rpg: I prefer this, because the objects may not be *re*constructed since
  they might not have been constructed in the first place. Also, ``instructions''
  might never appear, only some collaboration need be implied:
   
  COMPILE-FILE, on the other hand, must produce an output file which
  when loaded with LOAD constructs the objects defined by the source
  code.]

I prefer this also.  The only problem is that the objects aren't always
actually constructed, sometimes they already exist and are just referenced.
It's not clear that fixing that would improve understandability, so leave it.

However, it mandates some rewording of the next paragraph since it is no
longer clear what EQL relationship is being referred to.  I offer:

In the case of COMPILE-FILE, we cannot speak of objects constructed by
LOAD of the output file being EQL to objects constructed at compile
time, since the compiled file may be loaded into a different Lisp image
than the one that it was compiled in.  This section defines a notion of
"similarity as constants" which relates objects in the the compile time
environment to the corresponding objects in the load time environment.

  % Issue COMPILE-FILE-SYMBOL-HANDLING defines how the file compiler
  %  and loader handle interned symbols.
 
This sentence can't be commented out without replacing it with something.
Commenting it out leaves the discussion of symbols incomplete.

  Two arrays are similar as constants if the corresponding values each

of each

  For arrays of other dimensions:

other rank

I read through to the end but have no other comments right now.
I might comment on the next revision though.