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

[Faré]

>>: 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.

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


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

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

> 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.
>
I don't get it.

>   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.
>
Can do. What would that buy us?

>   output-files has an :around method which could be specialized.
>
And your conclusion is?

> are there other modifications?
>
> are there other methods?
>
We don't have to deal with every possible corner case
that someone could dream of.

But we do have to deal with things that actually happened in previous
versions of ASDF that people may upgrade from, and corresponding clients
that somehow use ASDF.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Death is only a state of mind.

Only it doesn't leave you much time to think about anything else.