semantics of copy and mirror Peter McGoron (21 Mar 2026 17:39 UTC)
Re: semantics of copy and mirror Daniel Ziltener (21 Mar 2026 23:06 UTC)
Re: semantics of copy and mirror Peter McGoron (22 Mar 2026 00:10 UTC)
Re: semantics of copy and mirror Daniel Ziltener (23 Mar 2026 20:12 UTC)
Re: semantics of copy and mirror John Cowan (23 Mar 2026 21:03 UTC)
Re: semantics of copy and mirror Daniel Ziltener (27 Mar 2026 21:33 UTC)
Re: semantics of copy and mirror jobol (24 Mar 2026 06:46 UTC)
Re: semantics of copy and mirror Daniel Ziltener (27 Mar 2026 21:41 UTC)

semantics of copy and mirror Peter McGoron 21 Mar 2026 17:34 UTC

The new draft looks nice, good to see that our name bikeshedding has
accomplished something :)

Some more questions/comments:

I don't think `copy` should make deep copying implementation-defined.
This can cause different performance and also subtle operational changes.

Would it be possible to allow for implementation extensions to the
default slots of the root object? I am not sure of the consequences of
such an action, but then deep-copying implementations can implement a
deep-copy method.

How does mutating the mirror object of an object affect the object?

Does the "raw list" in immediate-ancestor-list and full-ancestor-list
mean that the list shares state with the object in some way? The
definition of immediate-slot-list and full-slot-list do not specify that
they return "raw list"s.

It also mentions that the elements are copied as-if by `list-copy`
(which is now standard in the R⁷RS). Does that mean that all objects
implement their messages and slots as lists?

Super minor thing: the list of identifiers in the export lists should be
wrapped in <code> to make them look better.

-- Peter McGoron