Thank you for sharing your idea and feature request. Even if it may
not be solved by SRFI 237, it fits the discussion very well.  See SRFI
57, for example, for a record proposal that already included the idea
of pure updates.

In the context of the model of SRFI 237, a general update mechanism
does not make sense in the general case; conceptually, a record type
is more than its set of fields; each instance usually obeys invariants
(interdependences of the field values).  Any solution to the update
problem has to respect this.

An updater of a child record type should not have to deal directly
with updating the fields of its parent (because would breach an
abstraction barrier); instead, an updater of a child record type
should call a corresponding updater for a parent record type.

An updater is to be realized as a custom constructor; constructors are
chained (as we need it) from child to parent types.

I haven't yet thought about a high-level API to create updaters, but
SRFI 237 could easily offer an inspection mechanism for macro
transformers dealing with syntactic record types, complementing the
procedural inspection interface.  This would make it possible for a
third-party SRFI to implement something like:

(define-record-updater <updater-name> (<record-name> <parent-updater>)
<field-spec> ...)

Here, <field-spec> would somehow have to identify the fields to be
updated (note that the field name cannot be used because it is a
non-unique symbol).

Marc

Am Mo., 31. Okt. 2022 um 04:57 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> On Sun, Oct 30, 2022 at 6:36 PM Vladimir Nikishkin <xxxxxx@gmail.com> wrote:
>
>>
>> Would there be any benefit to having a default interface for "getting
>> a new object which is identical to the old one, except some of the
>> fields are different"?
>
>
> I, too, would love to see this in some SRFI.  I believe that Clojure has such a feature for dictionaries.  In Scheme, I find myself manually creating the equivalent for each record type on a per-case basis.