|
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
John Cowan
(27 Mar 2026 22:12 UTC)
|
|
Re: semantics of copy and mirror
Daniel Ziltener
(27 Mar 2026 23:39 UTC)
|
|
Re: semantics of copy and mirror
John Cowan
(28 Mar 2026 00:44 UTC)
|
|
Re: semantics of copy and mirror
Daniel Ziltener
(02 Apr 2026 22:09 UTC)
|
|
Re: semantics of copy and mirror
Peter McGoron
(02 Apr 2026 22:34 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)
|
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