Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)

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

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, 
loading, etc.). 

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.