[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: packages and portability
Our package setup is a bit different than the DEC proposal described
by Ugo Buy.
1. The 'lisp' package contains only those external symbols defined by
the book. [DEC would call this the common-lisp package. I could
see this name change being useful for people with existing lisps
who want to embed a common lisp into their lisp. If these people
come forth and lobby for it, I suppose I'll agree, otherwise I think
it should continue to be named lisp.]
2. The 'excl' package contains external symbols which are distinct from
those of the 'lisp' package, and these symbols represent most of
our extensions. We thus agree with DEC that each implementation should
define an extension package with a unique name. We don't think that
the lisp package symbols should be imported into this package
(more on this below).
3. If extensions must be made to the functions in the book, (i.e. symbols
in the lisp package) they are made only where upward compatibility
is preserved, and it is clearly documented in the manual that these
are non-portable extensions. [What I'm talking about are
things like extra keywords to 'compile-file'. The list of such extensions
will always be less than a page].
4. The 'user' package uses both the 'lisp' and 'excl' packages in the
version of common lisp we ship. It is a simple matter to unuse
the 'excl' package in your init file (or globally for all users)
if you want a pure common lisp. [as long as you don't use the
lisp package function extensions documented it the book]
5. The default use list for the make-package and in-package functions
is still the 'lisp' package. This is important, it makes the user
identify non-portable code. It prevents the user from running
ExCL only code in Vax-Lisp (as soon as the in-package is executed,
Vax-Lisp will complain about a missing excl package).
In point (2) I mentioned that the excl package doesn't contain the lisp
package symbols. This permits you to go into extended mode with a
use-package and out of extended mode with unuse-package (in the DEC mode,
the package switch is more complex). But more important, I think that
our way is 'extensible' to the future when extensions come in their own
package. In fact right now we have our standard extensions in the 'excl'
package, but we also have a 'foreign-functions' package, two graphics packages,
a flavors package, a 'cross-reference' package, etc. In our model, you
can simply use the packages you want to work in. The excl package extensions
aren't treated any differently than the other extensions and I don't see
why they should be.