Forum: Public Review
References: Barrett's public review comment #26
Loosemore's public review comment #7
Edit history: 20 Dec 1992, Version 1 by Loosemore
Status: Proposal RESTORE-ARGUMENT passed 11-0 on letter ballot
In the base document (CLtL), the REQUIRE function was specified as
accepting a required module name argument and an optional pathname
argument. In the current specification, the optional pathname
argument has been removed. The rationale given for this in
X3J13/91-415 is that it was the second argument that led to
portability problems. This claim is incorrect. It was the case that
both the one argument and the two argument forms had portability
problems in the past, but the addition of logical pathnames made the
two argument version easier to use in a portable way. Elimination of the
second argument means that we're left with the same problem the single
argument form has always had, namely that there are several competing,
incompatible mechanisms for dealing with the situation where the
module being required has not already been provided.
Restore the optional pathname argument to REQUIRE, as specified
in the base document.
Replace the examples with ones that better illustrate portable and
nonportable uses of REQUIRE, such as those suggested below.
Restoring the second argument makes it at least *possible* to use
REQUIRE in a portable way.
;;; This illustrates a nonportable use of REQUIRE, because it
;;; depends on the implementation-dependent file-loading mechanism.
;;; This use of REQUIRE is nonportable because of the literal
;;; physical pathname.
(require "CALCULUS" "/usr/lib/lisp/calculus")
;;; One form of portable usage involves supplying a logical pathname,
;;; with appropriate translations defined elsewhere.
(require "CALCULUS" "lib:calculus")
;;; Another form of portable usage involves using a variable or
;;; table lookup function to determine the pathname, which again
;;; must be initialized elsewhere.
(require "CALCULUS" *calculus-module-pathname*)
Cost to implementors:
Cost to users:
Having a feature in the language which is impossible to use portably
The changes are confined to the dictionary entry for REQUIRE.
The proposal to restore REQUIRE to the language without its second
argument was brought up at the Dec 1991 meeting without the benefit of
a formal writeup or any advance discussion on the mailing list, which
accounts for the resulting technical blunder. We don't have a very
good record when it comes to technical decisions made on the fly at
Loosemore says: I would still prefer to remove this broken feature
from the language entirely, but I'd rather not waste any more time
arguing about that given that some people seem to feel strongly about
keeping it in. I'm willing to accept proposal RESTORE-ARGUMENT
as a compromise, but doing nothing would not be acceptable to me.