Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)

[Jon L White <jonl@lucid.com>]

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
    extensions.

Read on!

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 --