compile-time processing of REQUIRE

[edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)]

re: Am I correct that REQUIRE forms appearing at top level are not supposed
    to be evaluated at compile time?  It is not in the list of magic
    functions on p. 182 of CLtL.  However, both VaxLisp and Lucid . . . 

I have been under the impression that the compilation interface is one 
area where CLtL, as a specification, didn't succeed very well.  Although 
no complete guarantee can be given to insure package layout consistency, 
it seems to me that the usage pattern of REQUIRE (but *not* PROVIDE) is 
such that it should be implicitly recognized by the compiler interface.

For example, see Table 11-1 of CLtL, p189:
    ;;;; Lisp init file for I. Newton
    ;;; Set upthe USER pacakge the wayk I like it.
    (require 'calculus)                ;I use CALCULUS a lot.  Load it.
    (use-package 'calculus)            ;Get easy access to its exported symbols
    . . . 
    ;;; Import only what I need into the USER package. 
    (require 'relativity)
    (import '(relativity:speed-of-light)...)

Quite evidently, the CALCULUS package is created and set up by the
calculus module; and parameters with names like RELATIVITY:SPEED-OF-LIGHT
are defined in the RELATIVITY module (indeed, isn't this the intention of 
"modular" programming!).  Thus this example, as a file, would not be 
compilable unless the REQUIRE statements are executed, in the order in 
which they appear, during the file compilation.

In addition to REQUIRE, Lucid has added UNINTERN to the set of forms
implicitly wrapped in an eval-when(eval compile load).  Note that there
is nothing stopping the programmer from using his own wrappers, which
will have precedence over the implicit one.

Incidentally, one other area where I personally violate the CLtL 
suggestions on package usage is in the placement of PROVIDE statements.
Section 11.9 suggests placeing them first in a file, and the cutsy little
mnemonic on page 191 -- PutInSevenExtremelyRandomUserInterfaceCommands --
also does that.  But because loading a lisp file is a dynamic action
with ocasionally loooooong duration, and because it is very easy to
abort the loading right in the middle -- either interactively or through 
the error system -- then I place my PROVIDE's last, so that the *MODULES* 
list will not actually be updated until the whole module is fully present.


One final point: I've used the word "statements" to refer to these
functions.  I hope you don't think that I'm just some kind of nerd who
learned Lisp yesterday and doesn't know enough to refer to these sorts 
of things as "forms" or "s-expressions" or whatever.  In fact the 
functionality provided by these "...ExtremelyRandomUserInterface..."
commands is very much like that of a JobControlLanguage.  That is why 
I refer to them as "statements".  

Allow me, if you will, to express one more very strong opinion:  I 
definitely prefer to write my "statements" in Lisp syntax rather than 
in YAJCL*, or FORTRAN, or even the Emacs-inspired "File Attribute"
syntax of the MIT Lisp machine descendents.  [Lisp is "good enough";
it does the job.]


-- JonL --


*  =  YetAnotherJobControlLanguage