Jean-Claude the point is that CLOS is not a "library", although it was certainly possible to implement it that way.. It is an integral part of CL "as is".
I see that the discussion has gone ahead, but here is my 2 cents. I don't have much time to work on it due to my day job (and other - retrocomputing - distractions). First of all there are several issues with CL which need to be clarified. - Some time ago, I started looking at reviewing the condition hierarchy. The motivation being the fact that (read-from-string "I-AM-NOT-A-PACKAGE::FOO") yields different conditions in different implementations. This is just an example: there are many, many more. - If your really want to help a "smart enough compiler" to produce fast code, what about writing up a precise explanation, wrt the current CL standard of what an extension like (defclass foo (a1 a2 ... an) (... slots...) ... (:sealed t)) should actually do? - I still would like to be able to write an interval arithmetic package in Common Lisp (yes; I may have hooked up a student to finish the grunt work of producing an initial spec that could be discussed in detail. - Can we have a common and Common Lispy network interface? - Did I mention (pathname-device some-pathname) ? The list can go on. But what I have in mind are all clarifications and extension to the CL spec as is. Not that there aren't libraries out there that do some or most of what I have in mind, but that's' the way things are right now. All the best Marco On Wed, Dec 9, 2020 at 10:11 AM Jean-Claude Beaudoin < jean.claude.beaud...@gmail.com> wrote: > > > On Wed, Dec 9, 2020 at 3:16 AM Nick Levine <n...@nicklevine.org> wrote: > >> > Can I ask why you invoke #'CL:CHANGE-CLASS on an object instead of >> simply creating a new instance of the second class with adequate >> initialization? >> >> Because you’d have to go find all the pointers to the old instance. Maybe >> you don’t want to do that. Or maybe you don’t care, but that’s ok because >> what CLOS gives you is possibilities. >> > > Yes, preserving instance identity is at the core of the question. It could > even be the only question here. Is there any other? > > But what looks like an occasional convenience comes at a cost. > > >> Class redefinition is cheap, in the sense that until you touch each >> instance (i.e. passing it to a method) no work is done on it. I suspect — >> but can’t remember the details — that cl:change-class recalculated slots on >> the spot. >> >> - nick >> > > > BTW, I just remembered that PCL (that venerable demonstration > implementation of CLOS) contains all the machinery needed to implement that > identity preservation feature as application level code expressed in CLTL1 > compatible code. > So this shows that the whole thing could be implemented as a > library/package all from the beginning. > It is a proof of concept of some kind I would say. > > -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY