[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
- To: pierson%mist@multimax.ARPA
- Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
- From: Jon L White <firstname.lastname@example.org>
- Date: Wed, 21 Sep 88 17:15:24 PDT
- Cc: email@example.com
- In-reply-to: Dan L. Pierson's message of Tue, 13 Sep 88 18:00:34 EDT <8809132200.AA01990@mist.UUCP>
I support this proposal. It's definitely the most positive step short
of flushing REQUIRE that can be taken with the modules mess.
Note that I'm not in favor of flushing REQUIRE/PROVIDE simply because
they don't meet the overexpectations outlined below. Rather, given
the acceptance of your proposal, they would play the limited role of
a "safety net" underneath the currently-vendor-specific DEFSYSTEM
facilities, and they would be fully portable in that role.
In particular, there are many persons in the community who confuse the
PROVIDE/REQUIRE pair with some limited sort of DEFSYSTEM. This is a
major mistake. Symbolics provides it's own propietary DEFSYSTEM with
it's product; and Lucid is providing a similar sort of thing with it's
release 3.0 (LUMEN). However, I don't believe we are currently in a
position to discuss standardizing a more complete, portable module
dependency and system building facility (via ordered file compiling,
In the meantime, your proposal should cut out the wart on REQUIRE that
tempts so many to treat it as some kind of cheap replacement for a
DEFSYSTEM. That is, a REQUIRE statement should not be viewed as
expressing merely a "latent" dependency of one module upon another, but
rather as a way of saying "do not proceed until this facility is fully
available". This is especially useful when loading files, since
irreparable damage can be done *** merely by reading in a file *** if the
packages which the current package inherits from are not fully "set up".
Also, there is often a tendency to confuse package and modules; as
defined in CLtL, the only clear course is to treat them as orthogonal
facilities that intersect only in so far as the initialization of a
package layout may be performed by a REQUIRED module.
In fact, a *very* reasonable scenario is to have several modules all "in"
the same package, and the specify, in whatever implementation-dependent
way one can, that the very first file/module to be loaded is the one
that creates all the packages needed by the subsystem. If this package
creator file is a module all by itself, then a REQUIRE for it from other
files isn't so much an attempt to lazyily create the needed packages,
but simply to ensure that the other files will not be loaded before the
requisite packages are fully set up. It is in this role that REQUIRE can
be most useful -- in giving an early error signal when something is being
done out of order, rather than the late signal raised by "name conflicts".
. . .
Another facet of "module" often overlooked is that it is an abstract
notion that need not be co-incident with a file. You could just as
easily "provide" the facilities encompassed in the module by compiling
"in core", by SETQ'ing, and so on, as you can by loading in some specific
named file. [Indeed, this kind of dynamic is Lisp's beauty over the
"conventional" programming languages]. The PROVIDE function is merely
the announcement that the "facility" is available. Of course, it goes
without saying that one may call REQUIRE from places other than the
toplevel forms of a file.
Consequently ,I take it as obvious that a module which is contained in a
file (i.e., it is "provided" by loading the file) cannot truly be said to
be "provided" until the whole file is loaded in. In such a case, it
means putting the PROVIDE statement at the end of a file, as you suggest.
At least one vendor I know of recommends putting the PROVIDE first, and
has buggered its LOAD function to notice these top-level calls and to
call UNPROVIDE if the file loading is aborted. The flaw in this is that
during the dynamic interval of loading, the value of *MODULES* is "lying"
in that the remaining portions are not in fact available. Similarly,
if a file is aborted after being half loaded (and the module is unprovided)
then *MODULES* will still be lying, since the earlier facilities indeed
have been "provided".
About the only excuse I've heard for requesting this behaviour (the "lying"
PROVIDE) is that one wants to have two mutually-dependent files, but not
to specify that one must be loaded first before the other one is loaded.
Quickly, you see the long arm of the "cheap shot" DEFSYSTEM intruding again.
-- JonL --
P.S. This note was delayed due to a mail system gaff. However, looking
ahead into the mails, I see that you were already proposing to
accommodate the mututally-requiring files by suggesting the LOAD
time "back out" of an early PROVIDE. I hope the above comments can
provide some a basis for agreeing not bugger LOAD this way after all.