[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
- To: cl-cleanup%sail.stanford.edu@multimax
- Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
- From: Dan L. Pierson <pierson%mist@multimax.ARPA>
- Date: Tue, 13 Sep 88 18:00:34 EDT
Sorry for the delay in this, but I've been waiting for preliminary
comments from an (unnamed) member of this committee...
References: *MODULES*, PROVIDE, REQUIRE, pp 188-191
Edit history: Version 1 by Pierson 9/13/88
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. The
error can be corrected by loading the appropriate file(s).
Note that there is no requirement that a module consist of exactly one
Change the "Put in seven extremely random user interface commands"
discussion to suggest that PROVIDE should be put at the end of the
file rather than the beginning.
Would still be legal.
(REQUIRE 'fft "fft")
Would no longer be Common Lisp. However implementations could still
provide this as an extension.
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.
Putting PROVIDE at the beginning of a file is a mistake because the
file will still appear to be PROVIDEd if it fails to load. This may
cause files loaded later to fail mysteriously because the first failed
file didn't define expected constants or macros, etc.
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.