Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)

[David N Gray <Gray@DSG.csc.ti.com>]

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

The current proposal says:

  ... if the module is not present, REQUIRE signals a correctable error of
  type REQUIRE-ERROR.

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.

>    The point you are trying to make, if I read it 
> right, is that previously this "essentially upwards compatible" way was 
> applicable to forms like (REQUIRE <module>), but now would only be applicable 
> to those like (REQUIRE <module> <more-stuff>).

My point is that the behavior for the one-argument case that was required
by CLtL is now forbidden, and without an adequate reason.

>  How serious a problem is this change?

If REQUIRE cannot ever automatically cause the module to be loaded, then I
think it is worthless.   I would rather see it dropped from the standard,
leaving the description in CLtL as a common extension, than to have its
meaning completely changed.