Updating instances when classes are redefined is critical to interactive development with the REPL.

If you want to see why it's so critical, try working with Python and modifying a class definition. You have to shut down the interpreter and start over, which is a huge pain if your system has a big, complex state you want to preserve.


On 6 Dec 2020, at 22:52, Jean-Claude Beaudoin 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?

Reply via email to