[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
- To: cl-cleanup%sail.stanford.edu@multimax
- Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
- From: Dan L. Pierson <pierson%mist@multimax.ARPA>
- Date: Mon, 17 Oct 88 16:13:42 EDT
- Cc: "email@example.com"@multimax
Almost done. Please note the second paragraph of the new Rationale.
Would it be better to just restrict REQUIRE to the *MODULES* list? I
seem to remember that at least one implementation was unhappy with that.
References: *MODULES*, PROVIDE, REQUIRE, pp 188-191
LOAD, pp 426-427
Edit history: Version 1 by Pierson 9/13/88
Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
Version 3 by Pierson 10/17/88, remove PROVIDE locaction specs.
Status: For Internal Discussion
PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences. These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.
Remove the second argument from REQUIRE. Change the description of
The REQUIRE function tests whether a module is already present
(using a case-sensitive comparison); if the module is not present,
REQUIRE signals a correctable error of type REQUIRE-ERROR.
This gives the user the opportunity to load the appropriate files
from the debugger before continuing.
Note that there is no requirement that a module consist of exactly one
Change the description of PROVIDE to:
"The PROVIDE function adds a new module name to the list of
modules maintained in the variable *MODULES* and possibly performs
other implementation-dependant actions to indicate that the module
in question has been loaded."
(There is no need to make a corresponding change to the definition of
REQUIRE, because it doesn't mention *MODULES*.)
Would still be legal.
(REQUIRE 'fft "fft")
Would no longer be Common Lisp.
The file loading feature of REQUIRE is non-portable. Since we can't
figure out an acceptable portable solution, the feature should be
flushed. Making REQUIRE signal a correctable error gives the user an
easy out in interactive situations.
REQUIRE is not required to use *MODULES* as it's database of loaded
modules in order to permit environment-specific extensions which
derive the loaded module database from other information. While it is
always safe, and good practice, to explicitly PROVIDE every module, it
may not be necessary in all implementations.
All implementations that I know of currently support a second argument
to REQUIRE. Lucid and KCL use the second argment at the pathname to
load relative to the current working directory.
Cost to Implementors:
All currently conforming implementations will have to make a small
Cost to Users:
Any (non-portable) user programs that rely on the current behaviour of
REQUIRE will have to change. On the other hand, porting Common Lisp
programs from one system to another may well be simplified because
REQUIRE errors will always correctable.
Cost of non-Adoption:
Part of the documented functionality of REQUIRE will continue to
unavailable to portable (and many non-portable) programs.
PROVIDE and REQUIRE will be clearly restricted to a portable,
This simplifies the language by removing an environment-dependent
Pierson supports this proposal.
This proposal creates an asymmetry in the handling of *MODULES* that
may bother some people.
Several people would like to simply eliminate PROVIDE and REQUIRE from
the language and either leave this language space empty or provide a
portable DEFSYSTEM standard. Others believe that PROVIDE and REQUIRE
are useful as a safety-net even in the presence of DEFSYSTEM. This
proposal attempts to reduce PROVIDE and REQUIRE to a well-defined
safety-net and leaves the question of DEFSYSTEM to a separate
proposal (which I don't intend to write).