Am Do., 21. Nov. 2024 um 21:34 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> I hope Arthur doesn’t mind me answering publically a comment he sent privately, since I think it sums up what may be some common responses to this proposal:
>
> > I have just one non-editor comment: Sometimes, I define several record types in a hierarchy, and they're meant to be used together, i.e. they're part of the same program.  In that case, I like having the ability to define a constructor for a subtype that includes all the fields of the supertype.  That reduces consing.  I hope that  R7RS Large won't lose that capability.
>
> 1. You can still do this, you just have to explicitly define a constructor procedure which takes the arguments you want; I expect that will be the most common way constructors of subtypes are used in practice, and the one defined by define-record-type itself is just a primitive used to build a slightly more palatable interface.
>
> 2. I considered the consing problem but also think that any compiler with a halfway decent inliner should be able to eliminate it in the common case when the first argument to the auto-defined constructor for a subtype is a call to any simple constructor for its supertype. Perhaps I should provide a third sample implementation where you can see that, for example, Chez’s cp0 is already basically capable of this (and that this can be seen with the expand/optimize procedure). The R6RS-based implementation doesn’t do this very well because it has to run circles around the R6RS record system to make it work the way it wants.

I was less concerned about Chez, and more about less optimizing
implementations (something as basic as records should be implementable
efficiently without too much effort).  Inlining is only the first
step; then, the implementation has to recognise that the creation of a
temporary record can be elided. For the auto-generated constructors,
this will likely be the case, but if one promise of this SRFI is
encapsulation and abstraction, the general case of a constructor that
does non-trivial work (e.g. by checking arguments or calculating field
values) should be equally considered (an example is given in the
SRFI).

But even if this problem is smaller than it may appear, abstract
record types would still have to expose a constructor that should not
actually be used as a constructor, which is, at least, inelegant.

> 3. I have no idea whether this SRFI is destined for R7RS Large. I consider it an experiment in trying to bring R7RS small records closer in terms of features to R6RS records.

Improving the R7RS small record system is certainly a good idea, but
it should be done in a way that makes interoperability with the R6RS
system trivial. In the case of the features of SRFI 256, this would
mean adopting the "protocol" protocol.  Is there a reason why this
couldn't be possible?