In CLOS, instance remorphing considered useless in practice?

[Faré]

I once used update-instance-for-redefined-class in ASDF, when I was
trying to make a smooth upgrade from ASDF 1 to ASDF 2. The problem I
found is that proper support for class redefinition requires the
cooperation not only of the underlying object system, but also of all
the parts of the implementation. It also requires more deterministic
guarantees on what code gets inlined and what code doesn't get
inlined.

In ASDF 3, I threw the towel, and decided I could never get the OTHER
parts of the system to cooperate (aka ASDF extensions for me, but also
all the extensions to all existing programs being redefined), so I
stopped using update-instance-for-redefined-class and instead went for
deleting/overwriting/resetting functions, generic functions, and, in
extreme cases, packages.

I would love to see languages with better support for redefinition.
Like unison, or darklang. Unhappily,
update-instance-for-redefined-class, while very cool, is *not enough*.

But in relatively small systems that are long-running, with everyone
cooperating, like they had in the 1980s, it was probably sufficient.
And it is a marvelous tool. If you control the entire application and
want images to survive code evolution.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Taxonomy is the death of science — A. N. Whitehead


On Tue, Dec 8, 2020 at 2:48 PM Jean-Claude Beaudoin
<jean.claude.beaudoin at gmail.com> wrote:
>
>
> Hello Pros of Common Lisp,
>
> Here is my attempt at starting a significant (and hopefully useful) debate on a subject squarely about Common Lisp and its internals.
>
> My main stance here is to state that I have yet to see, in a significant application, any use of functions #'cl:make-instance-obsolete and #'cl:update-instance-for-redefined-class and of the underlying machinery that support the remorphing of instances following a class redefinition (through a subsequent cl:defclass most likely). I can state the same thing about #'cl:update-instance-for-different-class and #'cl:change-class.
>
> The machinery required of any CL implementation to properly support those functions (mentioned here above) is quite significant in its complexity and usually imposes a sizeable performance penalty on the speed of any instance slot access.
>
> A different choice of class redefinition semantics can lead to an implementation of CLOS with much reduced instance slot access overhead.
>
> The necessity of supporting instance remorphing should therefore be well motivated by very significant gains in application code performance (in speed and/or size and/or expressiveness power).
>
> Can anyone of you point me to some evidence of such application level usefulness?
> Is there any notorious usecase of this (instance remorphing) since its inclusion into ANSI CL?
>
>
> By the way, at the bottom of the entry about #'cl:change-class in the text of the CL standard, one can find a "Notes:" section that starts with this sentence: "The generic function change-class has several semantic difficulties." And this was written in the context of a single-threaded implementation, as ANSI-CL limited itself. I bet that almost all currently significant CL implementations are now multi-threaded, therefore the "several semantic difficulties" are greatly and gravely compounded. In my opinion, this makes proper motivation of usefulness all the more imperious. What do you think?
>
>