[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
- To: CL-Cleanup@SAIL.Stanford.EDU, pierson%mist@MULTIMAX.ARPA
- Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 13 Sep 88 18:49 EDT
- In-reply-to: <8809132200.AA01990@mist.UUCP>
This is an improvement, but I personally still consider the whole
PROVIDE/REQUIRE feature to be bankrupt for another reason, unrelated
to the file issue. Specifically:
If PROVIDE is at the top of a file, that will make mutually dependent
systems loadable. If it's at the bottom of a file, then mutually
dependent systems will recursively load ad nauseum (or will go back
and forth erring, depending on whether you have Pierson's cleanup).
That would seem to argue for putting PROVIDE at the top. But then, if
a file blows out, you've provided the module already and there is no
provision to have the PROVIDE undone.
Unless we require PROVIDE to cooperate with LOAD and to have the
PROVIDE info persist only if LOAD does a normal
(i.e., non-erring, non-throwing, ...) return would I really believe
in PROVIDE and REQUIRE. I could -really- get behind PROVIDE and REQUIRE
if we could work out the details of this kind of cooperation to everyone's
I would also buy into a further restriction on PROVIDE and REQUIRE which
said that it was not to be used for mutually dependent systems, and
that PROVIDE was recommended for use only after having actually done
the providing -- not at the head of the set of file(s).
In the absence of those concessions, I agree that Dan's cleanup is
reasonable, but I don't know to what good end. In my opinion, he's
optimizing a still-worthless utility.