[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Ram@c.cs.cmu.edu
- Subject: REQUIRE
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Fri, 9 Oct 87 10:50:32 MDT
- Cc: "Robert W. Kerns" <RWK@scrc-yukon.arpa>, email@example.com, Sandra J Loosemore <firstname.lastname@example.org>
- In-reply-to: Ram@C.CS.CMU.EDU, Fri, 9 Oct 1987 11:37 EDT
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. The other problem is that
implementation-specific way that REQUIRE looks for the files to load if
you don't provide a specific pathname. I'm currently trying to get the
same bits of code to run under 4 different CL implementations (and
two different operating systems with incompatible filename conventions,
no less) and I've got the compiled files from each implementation living
in separate subdirectories....
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.