Issue: PACKAGE-CLUTTER

[Jon L White <jonl@lucid.com>]

re: I think this issue also needs to address the default value for :USEd
    packages.  (Or else the name should be changed to something more
    specific like LISP-PACKAGE-CONTENTS.)

Agreed.  Either change the issue name, or add an amendment addressing
the default value for the :use argument to make-package.


re: If we allow the default value for :USE to be implementation dependent,
    I think users would be most happy.  If someone really wants just Common
    Lisp, they would be able to say :USE '("LISP").  Otherwise they would
    be able to get the same environment that the USER package has, since
    implementations would have the flexibility to make them the same and
    as rich as they would like to make them.

 From the vendors point of view, I think this is an overriding issue.  
Nearly every vendor sells to a customer base in which users write code 
*primarily* for that vendor's Lisp.  Only a *very few* research 
establishments are propogating ideas in the form of portable code; 
and a couple of tools builders are supplying their product on many 
vendor's platforms.  Since there is only one option available for the 
:use default, Lucid has already decided to give the very tiny bias 
towards the overwhelmingly larger customer base.  The advantages to 
this larger "base" are:
   (1) Greater conformance of the vendor's documentation with what is
       actually available in the default package -- USER -- and in a
       new package made with the default options.
   (2) No need to insist that the vendor document all his extensions
       as, say, ACME-COMMON-LISP:WONDERFUL, but his manual can simply 
       say WONDERFUL without "qualification".
   (3) A few keystrokes less when typing MAKE-PACKAGE (or IN-PACKAGE).
Now, the downside for those actually writing portable code seems to be 
exactly null.  At worst it would merely mean that they would have to add 
an explicit :use argument to each call to MAKE-PACKAGE  (or to IN-PACKAGE).
However, as a practical matter, it turns out they have done this already. 
I remember Dave Plummer of Symbolics mentioning two years ago that even 
when not writing portable code, he never allowed the :use argument to be 
defaulted. [Why? I'm not sure, but having survived several internal 
changes myself, I suspect it was to insulate onself from the shifting 
winds of developement cycles.]

The issue is not portability, but rather deciding which part of the user 
community has to type those extra keystrokes.



re: I think this is what resulted from those CL discussions a few years ago.
    I'd guess that this is also what several implementations do.  Anyone
    care to comment?

I think so too.  [In fact, Lucid changed it's layout about a year ago to 
conform to what you describe].  In those discussions of 1986, I remember 
three main highlights:
   (1) The LISP package should not contain any symbols other than the 775 
       found in CLtL (which of course must be external);  several mail 
       iterations were required to get the several vendors to agree on 
       the specific list of 775.  Most people agreed on this issue, but
       there may have been one or two holdouts.
   (2) Vendor-specific extensions should not be put into *any* of the
       CLtL specified packages -- not even SYSTEM -- since by definition 
       they will not be portable, and since a coincidence of names in the
       "extensions" package between two different vendors would probably
       not imply the same functionality.
   (3) The favored suggestion (which may not have had consensus) for the 
       vendor-specific extensions was that they should be placed into a
       package named like ACME-COMMON-LISP for the "Acme" company.  Paul
       the greek even volunteered to maintain a registry of names for 
       such packages (but alas ...).



-- JonL --