not only this, if the symbol constituency changes, the notion of 'undefined' frequently yields results far from the intended. not to mention the (perhaps continuable) errors.
yes, one needs an operator with ensure-like semantics, which is intended to operate on packages which may already exist.
if this one-off defpackage equivalent is the only use-case - ie documentation, use, intern, export, the code for an ENSURE-PACKAGE is not _that_ bad.
On 2010-02-24, at 13:02 , Tobias C. Rittweiler wrote:
Current ECL HEAD comes with asdf version "1.604", but trying to load upstreams asdf.lisp won't work because of
"A package with the name ASDF-EXTENSIONS already exists."
Indeed, CLHS DEFPACKAGE says
If one of the supplied :nicknames already refers to an existing package, an error of type package-error is signaled.
In fact, using DEFPACKAGE for upgradability purposes is ill-conceived from the beginning because of:
If defined-package-name already refers to an existing package, the name-to-package mapping for that name is not changed. If the new definition is at variance with the current state of that package, the consequences are undefined; ...
And, e.g. the :EXPORT list changed in numerous points in past, and is not excluded from changing in the future.
The portable venue would be not to use DEFPACKAGE but either to define a DEFINE-PACKAGE macro on top of the functional layer yourself, or using the functional layer directly. Mwahaha. Suckage. :-)
-T.
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel