[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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
[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:
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 --