[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: masinter.pa@Xerox.COM
- Subject: Issue: PACKAGE-CLUTTER
- From: Jon L White <email@example.com>
- Date: Fri, 23 Sep 88 00:18:50 PDT
- Cc: firstname.lastname@example.org
- In-reply-to: masinter.pa@Xerox.COM's message of 20 Sep 88 00:37 PDT <880920-003738-3287@Xerox>
re: When you're about to release Lucid Common Lisp version 17, you'll be
glad that we made the default for :USE be LISP so that you could support
users who want to
:USE '("LUCID-3-0") ?
What's today a vendor-to-vendor issue is as likely to become a
version-to-version issue for you, no?
Absolutely not; in fact, I think you have it backwards. The simple path
of porting from and old version release to a newer one is SURELY thwarted
if the end user's code has calls like:
(make-package ... :use '("LUCID-3-0"))
Only when the customer takes the default use list will he get the documented
environment. Consider when *default-make-package-use-list* changes from
("LISP" "LUCID-COMMON-LISP" "LU-GRAPHICS")
[I did mention didn't I that the extensions are found in a package that is
not version dependent -- namely, LUCID-COMMON-LISP.] In effect, Lucid
has guaranteed that at least the LISP and LUCID-COMMON-LISP packages will
be around, and that they will be changed to meet the demands of the Common
Lisp Language and of Lucid's primary extensions thereto.
The place for the explicit :use list is for "portable" code -- it doesn't
want any of the vendor-specific stuff from the old release, and it doesn't
want any from the new release either!
One must remember that porting code from older releases to newer ones does
require user involvement. For a programmer who makes use of the vendor-
specific extensions, it cannot be solved merely by restricting the package
use list. Successive releases of Vendor Common Lisp will no doubt have a
few more symbols in them than earlier releases had [sigh, not likely that
very many will be removed]. An explicit :use list in customer package
creations will not shield him against such additions or deletions; but in
fact could put him in an partial environment that doesn't make much sense.
Of course, there will be applications which do want to supply an explicit,
non-default :use list -- for example:
("LISP" "SYSTEM" "VENDOR-COMMON-LISP" "GRAPHICS")
and these will require more than the usual amount of attention when the
vendor inflicts a major release cycle upon that community. Not only will
such users have to peruse the differential documentation, but they will have
to peruse all their code for :use lists that may no longer be workable.
-- JonL --