[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
- To: Gray@DSG.csc.ti.com
- Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
- From: Jon L White <email@example.com>
- Date: Tue, 1 Nov 88 23:28:11 PST
- Cc: firstname.lastname@example.org, pierson%mist@MULTIMAX.ENCORE.COM, CL-Cleanup@SAIL.Stanford.edu
- In-reply-to: David N Gray's message of Fri, 28 Oct 88 10:53:24 CDT <2803046004-4897841@Kelvin>
re: > ... Since the force of this proposal is to
> retract any _standard_ way to hook REQUIRE into LOAD/DEFSYSTEM, then it
> would still be OK for an implementation to extend REQUIRE in an
> essentially upwards compatible way.
. . .
According to the new error terminology, this seems to rule out any
possibility of an implementation extension. An "implementation may be
extended" clause would need to be added if the intent is to permit
re: My point is that the behavior for the one-argument case that was required
by CLtL is now forbidden, and without an adequate reason.
But the two-argument case is the one in which I suggested that an
implementation can extend in an "upward-compatible" way. That is,
the vendor's extension is upward-compatible with the portable definition
providing he achieves the "old" behaviour by doing (REQUIRE <file> NIL).
re: If REQUIRE cannot ever automatically cause the module to be loaded, then I
think it is worthless.
The problem is that the specification of how to do this can only be an
implementation-dependent extension. Unless someone solves the
universal file name problem. But removing them totally from the
language is much worse since that even breaks the code of those who
use PROVIDE/REQUIRE as a standardized "handshaking" signal (i.e.
without the interdependence to defsystem).
-- JonL --