... I forgot. Let's get the CLtL2 "Environment" API back in the "extended" spec.
Which brings me to the following statement. The issue here is to *extend *the spec; not to cut pieces out of it. All the best. Marco PS. Nag, nag. :) ABCL crowd! You said you were going to bring the environment API in "Very Soon Now" (tm). I have not checked the latest and greatest ABCL, but is it in now? :) :) :) On Wed, Dec 9, 2020 at 12:07 PM Marco Antoniotti <marco.antonio...@unimib.it> wrote: > 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 > -- 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