In CLOS, instance remorphing considered useless in practice?

Marco Antoniotti marco.antoniotti at
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>

> 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.beaudoin at> wrote:
>> On Wed, Dec 9, 2020 at 3:16 AM Nick Levine <nick at> 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
> 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
Viale Sarca 336
I-20126 Milan (MI) ITALY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the pro mailing list