[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Friday, 9 October 1987 12:50-EDT
From: sandra%orion at cs.utah.edu (Sandra J Loosemore)
To: Ram at c.cs.cmu.edu
This means that doing a LOAD may not make definitions available to a
following COMPILE-FILE. This is what REQUIRE is for.
Well, maybe that's what REQUIRE was intended to be used for, but I'm
afraid it hasn't turned out that way in practice. Portability problems
with PROVIDE and REQUIRE are currently #2 on my list, after problems
with top-level forms. In fact, it appears that many (most?) CL
implementations insist on treating PROVIDE and REQUIRE specially when
they appear as top-level forms.
This may be just a mental block on my part, but I always used to
wonder why anyone would use PROVIDE/REQUIRE at all. More recently I
came to the conclusion that their reason for existence was to state
compile-time dependencies, i.e. loading macro packages at compile
time. If you believe this, then it is obvious that the compiler must
evaluate REQUIRE at compile time.
But on reading the manual just now, I don't see any support for this
theory that REQUIRE is a mechanism for dealing with compile-time
Probably anyone who either:
a] Has strong beliefs about what PROVIDE/REQUIRE should do, or
b] has a good solution to the compile-time dependency problem
should speak up.
It does seem to be useful to have some syntax attached to the code
file that the compiler can recognize as an explicit manipulation of
The other problem is that implementation-specific way that REQUIRE
looks for the files to load if you don't provide a specific
pathname. [...] If it were up to me, I'd like to see a variable
named something like *REQUIRE-PATHNAME-DEFAULTS*, which specifies
where REQUIRE should look for modules if you don't give an
Having some standard mechanism for specifying a library search-list
seems reasonable. We have this capability, but implement it using our
"logical device" mechanism. Note that having simple default
interpretation for REQUIRE without a pathname doesn't prevent
implementations from providing alternate interpretations as long as
the simple version still works.