<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 7 Dec 2020, at 05:52, Jean-Claude Beaudoin <<a href="mailto:jean.claude.beaudoin@gmail.com" class="">jean.claude.beaudoin@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Hello Pros of Common Lisp,</div><br class="">Here is my attempt at starting a significant (and hopefully useful) debate on a subject squarely about Common Lisp and its internals.<br class=""><br class="">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 <span class="" style="" id=":6uj.27" tabindex="-1">remorphing</span> of instances following a class redefinition (through a subsequent cl:<span class="" style="" id=":6uj.28" tabindex="-1">defclass</span> most likely). I can state the same thing about #'cl:update-instance-for-different-class and #'cl:change-class.<br class=""><br 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 <span class="" style="" id=":6uj.29" tabindex="-1">sizeable</span> performance penalty on the speed of any instance slot access.<br class=""><br class="">A different choice of class redefinition semantics can lead to an implementation of <span class="" style="" id=":6uj.30" tabindex="-1">CLOS</span> with much reduced instance slot access overhead.<br class=""><br class="">The necessity of supporting instance <span class="" style="" id=":6uj.31" tabindex="-1">remorphing</span> should therefore be well motivated by very significant gains in application code performance (in speed and/or size and/or expressiveness power).<br class=""><br class="">Can anyone of you point me to some evidence of such application level usefulness?<br class="">Is there any notorious <span class="" style="" id=":6uj.32" tabindex="-1">usecase</span> of this (instance <span class="" style="" id=":6uj.33" tabindex="-1">remorphing</span>) since its inclusion into ANSI CL?<br class=""></div></div></blockquote></div><div class=""><br class=""></div><div class="">The implementation of ContextL relies heavily on the CLOS MOP, and among other things on runtime class redefinition and corresponding updates of class instances. You can find the details how the class redefinition machinery is used in cx-partial-class.lisp at <a href="https://github.com/pcostanza/contextl" class="">https://github.com/pcostanza/contextl</a></div><div class=""><br class=""></div><div class="">To the best of my knowledge, ContextL is one of the most efficient implementations of context-oriented programming (as compared to other implementations of COP for Java, Smalltalk, and a few other languages). This is because there is enough machinery in the CLOS MOP that provides the necessary dynamism and efficiency at the same time.</div><div class=""><br class=""></div><div class="">ContextL has been used in production, so should count as relevant.</div><div class=""><br class=""></div><div class="">Removal of features can lead to more efficient implementation strategies, but also leads to less expressivity. It’s always difficult to draw a good line between what is good for most cases, and what is necessary for some. I, for one, am happy that CLOS MOP provides this amount of flexibility. There are enough OOP systems / languages with reduced expressivity (including ISLISP, Dylan, and some Scheme implementations) that we don’t necessarily need another one.</div><div class=""><br class=""></div><div class="">It has already been pointed out in this thread that you can always revert to the much more restricted defstruct. Maybe that one is too restrictive for your taste, but again, it is difficult to draw a good line between restrictive and expressive, and no compromise will make everybody happy.</div><div class=""><br class=""></div><div class="">I think CLOS could be even more flexible, without loss of efficiency, but that’s a different discussion.</div><div class=""><br class=""></div><div class="">Pascal</div><br class=""><div class="">
--<br class="">Pascal Costanza<br class=""><br class="">
</div>
<br class=""></body></html>