Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)

[gz@spt.entity.com (Gail Zacharias)]

It would be a lot easier for implementations to give PROVIDE/REQUIRE
reasonable semantics if CL wasn't so damn specific about how these functions
must be implemented.  As I recall CLtL basically states that PROVIDE must
immediately push the module name onto the user-visible variable *MODULES*,
and REQUIRE must check if the module name is on *MODULES*.  This doesn't leave
much room for improvement, in that any divergence from this proscription could
be detected by some theoretical program manipulating/examining *MODULES*
directly.

Coral decided that in practice the mutually dependent systems problem is more
important than strict conformance, so our REQUIRE checks a separately
maintained list of modules being loaded and punts on them even if they're not
on *MODULES*.  Nobody has ever complained.

 From my point of view, the ideal solution would be for *MODULES* to be removed
 from the language, or at least make its relationship to PROVIDE/REQUIRE less
immediate.  Then we can talk about what PROVIDE/REQUIRE should do without
worrying about explicit manipulation of *MODULES* by user code.

As long as there is a chance that PROVIDE/REQUIRE could be fixed up, I think
it would be a mistake to state, as this proposal does, that PROVIDE should
appear at the bottom of the file.  Much of the descriptive power of PROVIDE is
lost if you have to put it (and hence the module name) out of view.  It's
certainly easy enough for implementations to achive the desired effect
regardless of where the provide happens to physically occur (if only provide
wasn't specified in terms of immediate effects on *modules*), so why put the
burden on the user.