CLHS: Issue REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN Writeup

#

## Issue REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN Writeup

    Forum:		Public Review
    Issue:		REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN
    References:	Barrett's public review comment #26
    		Loosemore's public review comment #7
    		REQUIRE
    		Issue REQUIRE-PATHNAME-DEFAULTS
    		Issue REQUIRE-PATHNAME-DEFAULTS-AGAIN
    Category:	CHANGE
    Edit history:	20 Dec 1992, Version 1 by Loosemore
    Status:		Proposal RESTORE-ARGUMENT passed 11-0 on letter ballot
                    92-302.

    Problem description:

      In the base document (CLtL), the REQUIRE function was specified as
      accepting a required module name argument and an optional pathname
      argument.  In the current specification, the optional pathname
      argument has been removed.  The rationale given for this in
      X3J13/91-415 is that it was the second argument that led to
      portability problems.  This claim is incorrect.  It was the case that
      both the one argument and the two argument forms had portability
      problems in the past, but the addition of logical pathnames made the
      two argument version easier to use in a portable way.  Elimination of the
      second argument means that we're left with the same problem the single
      argument form has always had, namely that there are several competing,
      incompatible mechanisms for dealing with the situation where the
      module being required has not already been provided.

    Proposal (REQUIRE-PATHNAME-DEFAULTS-YET-AGAIN:RESTORE-ARGUMENT):

      Restore the optional pathname argument to REQUIRE, as specified
      in the base document.

      Replace the examples with ones that better illustrate portable and
      nonportable uses of REQUIRE, such as those suggested below.

    Rationale:

      Restoring the second argument makes it at least *possible* to use
      REQUIRE in a portable way.

    Examples:

      ;;; This illustrates a nonportable use of REQUIRE, because it
      ;;; depends on the implementation-dependent file-loading mechanism.

      (require "CALCULUS")

      ;;; This use of REQUIRE is nonportable because of the literal
      ;;; physical pathname.

      (require "CALCULUS" "/usr/lib/lisp/calculus")

      ;;; One form of portable usage involves supplying a logical pathname,
      ;;; with appropriate translations defined elsewhere.

      (require "CALCULUS" "lib:calculus")

      ;;; Another form of portable usage involves using a variable or
      ;;; table lookup function to determine the pathname, which again
      ;;; must be initialized elsewhere.

      (require "CALCULUS" *calculus-module-pathname*)

    Current practice:

      Who knows?

    Cost to implementors:

      Minor.

    Cost to users:

      None.

    Aesthetics:

      Having a feature in the language which is impossible to use portably
      is unaesthetic.

    Editorial impact:

      The changes are confined to the dictionary entry for REQUIRE.

    Discussion:

      The proposal to restore REQUIRE to the language without its second
      argument was brought up at the Dec 1991 meeting without the benefit of
      a formal writeup or any advance discussion on the mailing list, which
      accounts for the resulting technical blunder.  We don't have a very
      good record when it comes to technical decisions made on the fly at
      meetings.

      Loosemore says: I would still prefer to remove this broken feature
      from the language entirely, but I'd rather not waste any more time
      arguing about that given that some people seem to feel strongly about
      keeping it in.  I'm willing to accept proposal RESTORE-ARGUMENT
      as a compromise, but doing nothing would not be acceptable to me.

Copyright 1996-2001, Xanalys Inc. All rights reserved.