#

## Issue MAKE-PACKAGE-USE-DEFAULT Writeup

    Status: Passed, as amended
    Issue:        MAKE-PACKAGE-USE-DEFAULT

    References:    MAKE-PACKAGE, CLtL p183
                   "USER" package, CLtL p181

    Related issues: PACKAGE-CLUTTER

    Category:      CHANGE

    Edit history:  JonL White, 6-Oct-88 (version 1)
                   Masinter,  8-Oct-88  (version 2)
                   Masinter, 16-Mar-89, Version 3 (make amendments
    			per Jan 89 X3J13)

    Problem description:

    The proposal in the issue PACKAGE-CLUTTER would specify that
    implementation-specific extensions are not in the LISP package.

    With that restriction, access to implementation-specific features
    is awkward; it is necessary to always name the vendor-specific
    extensions in the :USE list of MAKE-PACKAGE or (if the proposal
    in DEFPACKAGE is adopted) in DEFPACKAGE.

    This forces users of a specific implementation to always have
    to type something to get the default set of features for that
    implementation, even if they have no intention of writing portable
    code.

    Proposal MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT

    Change the specification of MAKE-PACKAGE (and DEFPACKAGE, if
    adopted, and IN-PACKAGE, if IN-PACKAGE-FUNCTIONALITY is not
    adopted) so that the default for the :USE keyword is
    undefined. Normally, the default will include
    the packages containing the implementation-specific features.

    Portable programs should instead always specify :USE '("LISP")
    explicitly.

    Examples:

    (package-use-list (make-package "SOME-USER"))
    (package-use-list "USER")

    Test Cases:

    (assert
        (subsetp `(,(find-package "LISP"))
                  (package-use-list (or (find-package "SOME-USER")
    				    (make-package "SOME-USER")))))

    Rationale:

    Every implementation either already does the equivalent of this, or
    else has a confusing assymetry about the USER package (i.e., their
    extensions are "available" in USER, but not in SOME-USER).

    Current practice:

    TI and Lucid's  3.0 versions "implement" this proposal in that they set
    the default :USE argument to be a list of the LISP package and the
    implementation-specific package.

    In VAXLISP the LISP package is the implementation-specific
    package, which contains the 775 symbols supposed to be in the LISP packge
    along with all the extensions; the package named COMMON-LISP
    has only the 775.  Thus this implements the proposal in the sense that
    the inheritance of a package made with a default :USE list contains
    all the implementation-specific symbols -- not just the 775 "LISP" ones.

    Symbolics release 7, and Lucid's 2.1 release use only '("LISP") for the
    default MAKE-PACKAGE use list, but have the aforementioned assymetry
    about the USER package.

    Cost to Implementors:

    None; this relaxes a constraint imposed by CLtL.

    Cost to Users:

    In theory, every user porting code from one vendor to another would
    have to ensure that every package definition, via IN-PACKAGE or
    MAKE-PACKAGE, had an explicit :USE list.  This is probably at most
    a 5-minute text editor search.  But in fact this imposition is moot,
    since virtually every such user has *already* supplied explicit
    :USE lists; given the current practice, he has had no alternative.

    Cost of non-adoption:

    There will continue to be a lack of clear standardization in this area,
    especially since vendors are more willing to violate this apparently
    unuseful mandate from CLtL than they are to give up a minor bias towards
    their customer base.

    Performance impact:

    None.

    Benefits:

    This new default behaviour for package creation will permit
    documented extensions to appear on equal footing with the basic facilities
    in the LISP package.  It appears as though the _majority_ of any
    users are developing and running their code totally within the
    enviornment provided by that one vendor; hence it seems reasonable for
    implementations to bias their default use list towards those making
    frequent use of their specific extensions to Common Lisp.

    Esthetics:

    Some feel that fewer implementation-dependent loopholes in the language
    is preferable, even when the practical import is virtually moot.

    Discussion:

    Lucid "exposes" the default :use list as the value of the special
    variable *DEFAULT-MAKE-PACKAGE-USE-LIST*, so that at site-configuration
    time, one could do
    	  (setq *DEFAULT-MAKE-PACKAGE-USE-LIST* '("LISP"))
    to return to the 1984 CLtL behaviour.  [This is not being proposed
    at this time.]

         ----- Additional Comments -----

    " I don't like this proposal, but I made a note to myself about another
     reason that just occurred to me:  There is no syntax for getting the default
     (ie, system-dependent) package included if you want to -also- use some other
     package."

     - - - - - -

    "MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT is okay with me.
    I think it might be better to strengthen it and say that the
    default for :USE is identical to the use list of the USER package.
    Does anyone agree?

    In response to Kent's remarks, the issue is whether the default should
    be a portable way to get the local extensions, or a portable way to
    get the portable language without the extensions.  I think either of
    those choices is portable and reasonable, it just depends on what you
    want to make easier, which probably depends on whether a package is
    being set up for use only by a predefined program or for use by user
    typein and/or user-written programs, either of which are likely to
    expect the local extensions.

    Hence I would also accept a proposal to make the default for :USE
    continue to be the LISP package, rather than incompatibly changing it,
    and add a portable name for the local extensions."
     - - - - - -

    "re: I think it might be better to strengthen it and say that the
        default for :USE is identical to the use list of the USER package.
        Does anyone agree?

    I agree, sort of.  Especially since one of the motivating factors for
    this proposal was that some Lucid 2.1 user's were complaining that
    "things" look a lot different from the USER package than from a
    user-created package.

    The only question is whether or not you really want the default to be
    sensitive to subsequent alterations of USER's :use list.  As mentioned
    in the Discussion section of the proposal, Lucid's implementation
    exposes the default as the value of a global variable, which happens
    to be a copy of the initial :use list of USER; but subsequent changes
    to USER have no affect on this global variable."
     - - - - - -

    "The point:  non-portable programs should declare that intent up-front.
    This is a virtue of the current situation:  if the program uses a
    non-portable package, they have to state that at the head of the file.  Us
    poor losers who try to load it into the wrong environment get a error
    before we've gotten on with the load."

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