REQUIRE

[Ram@C.CS.CMU.EDU]

    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
    Re:   REQUIRE

        From: Ram@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
dependencies.

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
its environment.

    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
    explicit pathname.

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.

  Rob