[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: Compiler section (4.2)
Date: 16 May 89 0746 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
- 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: I'm imagining an implementation strategy in which a separate image
with a compiler compile-file's all input to the ``real Lisp'' and the real
Lisp loads it. You can also imagine that the ``real Lisp'' is clever to
batch up forms to be compiled to the compiler image, making the analogy
to a file more precise. Possibly this is stretching the point. (Also, the
collaboration between these two processes must be tight to provide the
right behavior according to what COMPILE must do.]
I don't think an analogy to a file is good enough if we're going to give
files such prominence that block compilation within one file is allowed but
across files is not allowed, which is my interpretation of what Sandra's
text quoted above says. I think I'd be happiest if we just left this part
referring to COMPILE-FILE as written. The implementation strategy you're
imagining might have to disable block compilation when compiling things
sent over from the Lisp, but I see no harm in that.
``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.''
[rpg: Quite right. How about this:
COMPILE-FILE, on the other hand, must produce an output file which when
loaded with LOAD constructs or references or both the objects defined by
the source code.]
Good. (I'd use "and/or" to avoid saying "or both"; either way is okay.)