Re: Suggested feature from EAK

[JonL at PARC-MAXC]

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
     version numbers.

  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
     original one).

  3)               LOADCOMP
        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.]