[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: REQUIRE-PATHNAME-DEFAULTS (Version 4)



Here's the reversal.  The Current Practice section is intentionally
abstracted because the proposed change is incompatible with everyone.

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.
	       Version 4 by Pierson 10/31/88, remove from language
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:ELIMINATE):

Remove PROVIDE and REQUIRE from the Common Lisp standard.

Test Cases/Examples:

(PROVIDE 'fft)

Would not be Common Lisp.

(REQUIRE 'fft)

Would not be Common Lisp.

Rationale:

The file loading feature of REQUIRE is non-portable.  The remaining
functionality of PROVIDE and REQUIRE (pushing and testing *MODULES*)
can easily be implemented by user code.  Since some implementations
will retain the automatic module loading features of REQUIRE and some
won't, use of REQUIRE will almost always make code less portable.

Current practice:

All implementations currently support some sort of file loading via
REQUIRE.  In general, the Lisp Machine implementations use the second
argument to invoke the system module building/loading facility while
the Unix implementations simply try to load a file in the current
directory.

Cost to Implementors:

Implementations will have to move PROVIDE and REQUIRE to their package for
implementation extensions and change their documentation to indicate
that PROVIDE and REQUIRE are non-standard.  This is a fairly small change.

Cost to Users:

Any (non-portable) user programs that rely on PROVIDE and REQUIRE may
have to change.  Since most implementations will probably keep these
functions as extensions to Common Lisp, this change will probably only
be required by user programs that wish to be portable.  Since the
current behavior is decidedly non-portable, these programs would
probably have to change anyway.

Cost of non-Adoption:

PROVIDE and REQUIRE will continue as impediments to portability.

Benefits:

The non-portability of PROVIDE and REQUIRE will be made obvious.

Aesthetics:

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

Discussion:

Pierson, Pitman, Fahlman, and Gregor support this proposal.

The cleanup committee tried to come up with a proposal to restrict
PROVIDE and REQUIRE to the portable subset of their functionality.
This failed because several implementors objected that it compelled
them to significantly reduce the functionality they provided users in
order to create a trivial feature which any user could easily write
for herself.