On 3/22/26 01:05, Peter McGoron wrote:

> Adding new identifiers to a library exported by an SRFI would be a
> violation of the spec of the SRFI, because those newly imported
> identifiers could conflict with other imported identifiers. (For
> example, if I made my SRFI 263 implementation export some identifier
> named `cons`).
Okay. I adjusted the `copy` message doc accordingly, and added a
`deep-copy` message that is declared as optional for implementers. I
definitely won't be able to implement this in pure R7RS, nor in my "day
to day" dialect of Chicken, but I think now that deep-copying is a
potentially valuable mechanic for some.
> > The lists themselves that are returned are shallow copies.
>
> Thank you for the clarification. One final one for this subject: do
> the lists of three elements of immediate-slot-list and full-slot-list
> or are they generated on each call?
>
> Since the lists are the same length and contain the same objects, it
> might be better to make them record types. Then I could access the
> information with slot-getter, slot-setter, slot-type, etc. Or they
> could be objects in the sense of this object system and have 'getter,
> 'setter, and 'type messages.

Good point, I originally intended to not use records at all for the
reference implementation, these being lists is a leftover from that in a
way - it's definitely more user friendly to use a record type for that,
which I now added. Making these objects would, imo, be overkill.

Regards,
Daniel Ziltener