In CLOS, instance remorphing considered useless in practice?

[Marco Antoniotti]

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 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20201209/b0c020fe/attachment-0001.html>