[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suggested feature from EAK
- To: Guy.Steele at CMU-10A
- Subject: Re: Suggested feature from EAK
- From: JonL at PARC-MAXC
- Date: Sat, 19 Jun 1982 02:38:00 -0000
- Cc: common-lisp at SU-AI
- In-reply-to: Guy.Steele's message of 17 June 1982 1421-EDT (Thursday)
Certainly something like this is necessary. (I must say that I'm impressed
with the facilities for doing such things in InterLisp -- DECLARE: likely
was the precursor of EVAL-WHEN.) EAK's conception of REQUIRE
seems to be a step in the right direction, and a couple of relevant points
from past MacLisp experience are worth noting:
1) VERSION NUMBERING
A few years ago when Bob Kerns and I hacked on this problem, we
felt that the "requirement" should be for some specific, named feature,
as opposed to the required loading of some file. (EAK may have been
in on those discussions back then). True, most of our "requirements"
were for file loadings (its certainly easy to make a "feature" synonymous
with the extent of some file of functions), but not all were like that.
There is a very fuzzy distinction between the MacLisp "features" list,
and the trick of putting a VERSION property on a (major component
part of the) file name to indicate that the file is loaded.
But a typical "feature" our code often wanted was, say, "file
EXTBAS loaded, with version number greater than <n>"; thus we'd make
some dumped system, and then load in a file which may (or may not)
require re-loading file EXTBAS in order to get a version greater than the
one resident in the dump. Simple file loading doesn't fit that case.
Xerox's RemoteProcedureCall protocol specifies a kind of "handshaking"
between caller and callee as to both the program "name" and permissible
2) FEATURE SETS
The facility that Kerns subsequently developed attempted to
"relativize" a set of features so that a cross-compiler could access the
"features" in the object (target) environment without damaging those
in the (current) compilation environment. (This was called SHARPC
on the MIT-MC NILCOM directory, since it was carefully integrated
with the "sharp-sign" reader macro). I might add that "cross-compilation"
doesn't mean only from one machine-type to another -- it's an appropriate
scenario any time the object environment is expected to differ in some
relevant way. Software updating is such a case -- e.g. compiling with
version 85 of "feature" <mumble>, for expected use in a system with
version 86 of <mumble> loaded. I believe there was a suggestion left
outstanding from last fall that CommonLisp adopt a feature set facility
like the one in the VAX/NIL (a slightly re-worked version of Kern's
Another trick from the InterLisp world: there are several varieties of
"load" functions, two of which might be appropriate for EAK's suggestion.
2a) LOAD is more or less the standard one which just gobbles down
the whole file in the equivalent of a Read-Eval loop
2b) LOADCOMP gobbles down only the things that the compiler would
evaluate, if it were actually compiling the file; the idea is to get
macros etc that appear under (EVAL-WHEN (COMPILE ...) ...)
Thus when a file is being compiled it can cause the declarations etc
from another to be snarfed; in actual use, LOADCOMP can be (and is)
called by functions which prepare some particular environment,
and not just by (EVAL-WHEN (COMPILE) ...) expressions in files.
[Since InterLisp file generally have a "file map" stored on them, it's
possible to omit reading any of the top-level DEFUN's; thus this
really isn't as slow as it at might first seem.]