... 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.antoniotti@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.beaudoin@gmail.com> wrote:


On Wed, Dec 9, 2020 at 3:16 AM Nick Levine <nick@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