In CLOS, instance remorphing considered useless in practice?
dbm at refined-audiometrics.com
dbm at refined-audiometrics.com
Tue Dec 8 20:19:22 UTC 2020
I am interested to hear arguments in both directions. But you haven’t outlined the alternative, other than to state that they exist. What are these alternatives?
I use these MOP functions indirectly whenever I perform a CHANGE-CLASS on objects, mimicking something akin to Smalltalk BECOME. And yes, many (most?) of my apps are mutlithreaded.
- DM
> On Dec 6, 2020, at 9:52 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?
>
>
More information about the pro
mailing list