In CLOS, instance remorphing considered useless in practice?

[Marco Antoniotti]

... 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 at 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 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
>


-- 
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/11048ce2/attachment.html>