Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Tue, 25 Oct 88  18:33:20 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> This proposal really does two things:
> 
>  1. It eliminates the second argument of REQUIRE.
>  2. It changes the meaning of calling REQUIRE with one argument from what
>     CLtL says at the bottom of page 188.
> 
> I agree with the first change.  I do not agree with the second change, and
> there is nothing in the "rationale" to justify it.  All of the discussion
> has been addressing the first change only.  Where did this second change
> come from?

The problem with calling REQUIRE without an argument, as it's
currently defined, is that you have no guarantee that it will know
where to find the right files.  There is not much point in having the
language specify a standard mechanism like this, if there is no
portable way to use it.  So, when the proposal says that the
file-loading feature of REQUIRE is nonportable, it's referring to both
the case where you give it an explicit pathname, and the case where
you don't.

My original proposal on this issue specified how REQUIRE should look
for files to load, using a search list of pathnames to be merged with
the module name.  (Implementations could still use some other
nonportable module registry mechanism if that failed to find
anything.) For various reasons, this idea was discarded by the cleanup
committee and for a time there was talk of flushing PROVIDE and
REQUIRE entirely.  Just about anything would be better than the
current situation, and I really don't have any problems with the
current proposal other than the one nit I've already brought up. 

The variation between implementations on what they do to REQUIRE
without a pathname argument is ridiculous.  As you've already noted,
the Explorer treats REQUIRE as a hook into DEFSYSTEM.  PCLS and HPCL-I
use a search list similar to what I originally was proposing, probably
because PSL had something similar.  VaxLisp (at least on VMS) uses a
logical name for the directory containing the files.  KCL looks only
in *DEFAULT-PATHNAME-DEFAULTS*, and I think that's what Lucid does too
(their documentation doesn't say).

-Sandra
-------