[asdf-devel] Package manipulation [ was ASDF traverse changed behavior? ]

[james anderson]

good afternoon;

On 2010-03-18, at 16:23 , Faré wrote:

> [ ...]
>
> 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.

package renaming : is not permitted
package deletion : is not permitted
package aliasing : is permitted, as long as the name is new

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

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.

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

variable rebinding : should be permitted. there are no constants.



wrt. methods on the basis of 1.648, there are very few methods which  
are not already fully specialized and as such amenable to such rules.

   perform-with-restarts has a default method as the next method for  
the :around methods. one could argue that this should be distinct  
base methods, but i don't see a clear reason to do that - especially  
as it is intended to be _the_ default method.
   output-files has an :around method which could be specialized.

are there other modifications?

are there other methods?