[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
compile-time processing of REQUIRE
- To: email@example.com
- Subject: compile-time processing of REQUIRE
- From: firstname.lastname@example.org (Jon L White)
- Date: Sat, 1 Aug 87 22:31:24 PDT
- Cc: email@example.com
- In-reply-to: Sandra J Loosemore's message of Fri, 31 Jul 87 23:02:05 MDT <8708010502.AA05593@orion.utah.edu>
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.
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