In CLOS, instance remorphing considered useless in practice?

[Jean-Claude Beaudoin]

On Wed, Dec 9, 2020 at 6:18 AM Marco Antoniotti <marco.antoniotti at unimib.it>
wrote:

> ... 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.
>
>
CLtL2 "Environment" API is second from the top of my list of things to do.
But I am of the opinion that this API needs one or two corrections before
being good enough for primetime. But currently I need first to finish my
C99-complete FFI thing.


> 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.
>>
>>
You have to hit directly on it to see what could be wrong with it. I cannot
do much about other implementations though.


>
>>    - 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 tried myself at this one quite a while back and got a very big
headache.  If I recall correctly my working conclusion was that this
:sealed option of cl:defclass was targeting the wrong thing.  The CPL of
the class was the real key instead and I could not see how to nail that
one. But that has been quite a while ago so I could be fabulating here.


>
>>    - 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.
>>
>> Looks like a "also nice to have".

>
>>    - Can we have a common and Common Lispy network interface?
>>
>> Such a nice candidate for a (standard?) library.

>
>>    -
>>    - Did I mention
>>    (pathname-device some-pathname)
>>    ?
>>
>> Specifically pathname-device alone or the whole pathname business?

>
>>    -
>>
>> 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
>>
>
Thank you very much for all this.

Regards,

Jean-Claude
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20201209/e8be2bb6/attachment-0001.html>