Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)

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

re: [implementationd-dependent extension] ...
    Similarly, (REQUIRE "FOO") should be defined as a standard way
    to invoke whatever module loading feature the implementation provides.
    You don't have to standardize how it is done in order to standardize how
    to ask it to be done.

Hey, I'll buy that.  This permits backwards compatibility for those
implementations that hook REQUIRE into their vendor-specific defsystem,
while at the same time permits those that don't have it to get the
"safety-net" feature.  I.e., the "hook" is merely a cerror call.
This still isn't going back on any part of the proposal that flushes
the second argument.  

Dan: would it be acceptable to you to alter the proposal and say that 
the action when the module isn't present is extendible by invoking any
implementation-specific "hooks"?

I still think (version 3) is an acceptable proposal -- especially after 
being emmended as above -- without superseding it with (version 4).  It 
is the least disturbance to the status quo that retracts the non-portability
parts.  Since there are many user's that do use the "safety-net" --
and do so in a portable way, I can't see flushing it simply in order to
continue the non-portable, non-standard usages.  I liked Larry's rationale
for it:

    Date: 18 Oct 88 14:13 PDT
    From: masinter.pa@Xerox.COM
    Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
    In-Reply-To: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>'s message of
     Tue, 18 Oct 88 15:27:25 EDT

    The thing that distinguishes PROVIDE and REQUIRE from their obvious
    implementations is that they have declarative rather than operative
    semantics. Program walkers, DEFSYSTEM constructors as well as compilers
    might be expected to pay special heed to PROVIDE and REQUIRE, but not pay
    any special heed to direct manipulation of *MODULES*.

    We should be careful in the standard to distinguish between what things
    mean and how they may be implemented, but doubly so in the case of macros
    and special forms that may get processed at times other than EVAL-time.


-- JonL --