[asdf-devel] upgradability with ECL

[james anderson]

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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel