[asdf-devel] upgradability with ECL
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.
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
On 2/24/10 Feb 24 -6:02 AM, 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. :-)
Another alternative would be to rename the package we are using, and then pass the exported symbols out through the ASDF package name later. That would allow us to keep defpackage, which is the preferred API for this task. Follow-up question: why do we need the ASDF-EXTENSIONS nickname? Can we sacrifice this instead of giving up DEFPACKAGE? Is it for backwards compatibility with some specific, small number of symbols that used to be in ASDF-EXTENSIONS? In that case it would seem to me more benign to use the functional interface to packages to fix the problem, and avoid using the package nickname. Best, r
Thanks to Tobias for his several bug reports. I committed fixes to the issues, building my own ensure-package (in a labels in cl-user, because we don't have a package in which to do a defun yet). RPG:
Follow-up question: why do we need the ASDF-EXTENSIONS nickname? Can we sacrifice this instead of giving up DEFPACKAGE? Is it for backwards compatibility with some specific, small number of symbols that used to be in ASDF-EXTENSIONS?
It is for backwards compatibility indeed. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] It is useless to attempt to reason a man out of a thing he was never reasoned into. — Jonathan Swift
Faré <fahree@gmail.com> writes:
Thanks to Tobias for his several bug reports. I committed fixes to the issues, building my own ensure-package (in a labels in cl-user, because we don't have a package in which to do a defun yet).
There's another thing bugging me: Could we add a PERFORM to swank.asd to muffle redefinition warnings? -T.
participants (4)
-
Faré -
james anderson -
Robert Goldman -
Tobias C. Rittweiler