Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)

[Dan L. Pierson <pierson%mist@multimax.ARPA>]

Almost done.  Please note the second paragraph of the new Rationale.
Would it be better to just restrict REQUIRE to the *MODULES* list?  I
seem to remember that at least one implementation was unhappy with that.

Issue:         REQUIRE-PATHNAME-DEFAULTS
References:    *MODULES*, PROVIDE, REQUIRE, pp 188-191
               LOAD, pp 426-427
Category:      CHANGE
Edit history:  Version 1 by Pierson 9/13/88
               Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
               Version 3 by Pierson 10/17/88, remove PROVIDE locaction specs.
Status:        For Internal Discussion

Problem description:

PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences.  These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.

Proposal (REQUIRE-PATHNAME-DEFAULTS:DECLARATIVE):

Remove the second argument from REQUIRE.  Change the description of
REQUIRE to:

    The REQUIRE function tests whether a module is already present
    (using a case-sensitive comparison); if the module is not present,
    REQUIRE signals a correctable error of type REQUIRE-ERROR.
    This gives the user the opportunity to load the appropriate files
    from the debugger before continuing.

Note that there is no requirement that a module consist of exactly one
file. 

Change the description of PROVIDE to:

   "The PROVIDE function adds a new module name to the list of
    modules maintained in the variable *MODULES* and possibly performs
    other implementation-dependant actions to indicate that the module
    in question has been loaded."

(There is no need to make a corresponding change to the definition of
REQUIRE, because it doesn't mention *MODULES*.)

Test Cases/Examples:

(REQUIRE 'fft)

Would still be legal.

(REQUIRE 'fft "fft")

Would no longer be Common Lisp.

Rationale:

The file loading feature of REQUIRE is non-portable.  Since we can't
figure out an acceptable portable solution, the feature should be
flushed.  Making REQUIRE signal a correctable error gives the user an
easy out in interactive situations.

REQUIRE is not required to use *MODULES* as it's database of loaded
modules in order to permit environment-specific extensions which
derive the loaded module database from other information.  While it is
always safe, and good practice, to explicitly PROVIDE every module, it
may not be necessary in all implementations.  

Current practice:

All implementations that I know of currently support a second argument
to REQUIRE.  Lucid and KCL use the second argment at the pathname to
load relative to the current working directory.

Cost to Implementors:

All currently conforming implementations will have to make a small
change.

Cost to Users:

Any (non-portable) user programs that rely on the current behaviour of
REQUIRE will have to change.  On the other hand, porting Common Lisp
programs from one system to another may well be simplified because
REQUIRE errors will always correctable.

Cost of non-Adoption:

Part of the documented functionality of REQUIRE will continue to
unavailable to portable (and many non-portable) programs.

Benefits:

PROVIDE and REQUIRE will be clearly restricted to a portable,
checking role.

Aesthetics:

This simplifies the language by removing an environment-dependent
feature. 

Discussion:

Pierson supports this proposal.

This proposal creates an asymmetry in the handling of *MODULES* that
may bother some people.

Several people would like to simply eliminate PROVIDE and REQUIRE from
the language and either leave this language space empty or provide a
portable DEFSYSTEM standard.  Others believe that PROVIDE and REQUIRE
are useful as a safety-net even in the presence of DEFSYSTEM.  This
proposal attempts to reduce PROVIDE and REQUIRE to a well-defined
safety-net and leaves the question of DEFSYSTEM to a separate
proposal (which I don't intend to write).