In CLOS, instance remorphing considered useless in practice?
marco.antoniotti at unimib.it
Wed Dec 9 11:17:42 UTC 2020
... 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.
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.antoniotti at unimib.it>
> 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
> On Wed, Dec 9, 2020 at 10:11 AM Jean-Claude Beaudoin <
> jean.claude.beaudoin at gmail.com> wrote:
>> On Wed, Dec 9, 2020 at 3:16 AM Nick Levine <nick at 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
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pro