[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: vanroggen%aitg.DEC@decwrl.dec.com
- Subject: Issue: PACKAGE-CLUTTER
- From: Jon L White <email@example.com>
- Date: Tue, 20 Sep 88 00:19:47 PDT
- Cc: firstname.lastname@example.org
- In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Wed, 14 Sep 88 07:46:51 PDT <8809141446.AA04055@decwrl.dec.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 --