On 3/18/10 Mar 18 -1:44 PM, Faré wrote:
: fare
: janderson
But I think ASDF ought to make a best effort, so that you can at the very least upgrade ASDF when installed as part of Common-Lisp-Controller and similar management layers (that do use package ASDF).
as a step in that direction, let us enumerate the actions which an upgrade could contemplate and come to terms with the consequences on existing code. in the note below, "not permitted" refers to a situation where the modification must be compatible with a running system and/or binary files, to be loaded as is, without recourse to source files for recompilation.
This deserves to be published in a document. Maybe a page on Cliki. Or a post on a blog, etc.
Proposal: let's get something like that written up on Cliki or a blog post by whoever has the energy to do it.
I would be willing to formalize it into Texinfo and stuff it into the manual if that's done.
Preference: absolute minimum of formatting in the text, so it's easy to translate into Texinfo (texinfo is more "semantic" than things like wiki markup or markdown, so it's tricky for me to use string replacement for much of the translation).
package renaming : is not permitted package deletion : is not permitted package aliasing : is permitted, as long as the name is new
OK.
symbol export : is not permitted, as the new export can conflict with the content of a using package
symbol unexport : is not permitted, as it could eliminate a previously visible symbol
symbol uninterning : is not permitted, as it would compromises existing references
Hum, yet, we do export new symbols, unexport and unintern old symbols and in practice, it works well enough.
I am inclined to agree: how can we not change the set of exports without fully locking ourselves into the existing API?
I /do/ agree that such changes should be minimized, though, and presumably should come with instructions about how to handle them in #+asdf<n> code blocks.
This is an interesting question --- what should one do if one expects that there might be a downstream incompatible change? Should one recommend that people write code like
#+(and asdf2 (not asdf3))
that seems cumbersome....
plain function redefinition as generic : if done with fmakunbound, this is permitted, as only the library definition can exist. generic function redefinition as plain : this is not permitted, as it could purge extension methods.
generic function redefinition : via defgeneric is permitted, that is, so long as the lambda list is compatible, as it should not effect extension methods. via fmakunbound is not permitted, as it could purge extension methods. this means that the present (ensure- package :fmakunbound) semantics must be changed to distinguish plain and generic functions.
Sometimes, we do want to purge extension methods. Especially when the extension protocol has changed. As in when the method-combination of some gf was recently obliterated, or simply when the signature of some methods have changed, and you don't want the old methods to be called anymore.
Presumably it's acceptable if purging extension methods causes an error, since we shouldn't be trying to load an extension that requires methods that no longer exist, right?
method deletion : as long as the method specializers are asdf classes or common-lisp classes, this is permitted, as this no extension function should fit that constraint. this could be automated independent of generic function redefinition as a means to clean a package of incompatible definitions. (ensure-package :fmakunbound) could use this approach.
method addition : same as deletion
method redefinition : same as deletion
Yes, but much heavier weight than now.
variable rebinding : should be permitted. there are no constants.
Tricky would be symbol being made un-constant or un-special. Would require unintern.
Question: if we have only internal constants (i.e., not exported and not for use in extensions), will that be safe?
Best, r