Re: Functional record “setters”

[Mark H Weaver]

Hi Ludovic,

address@hidden (Ludovic Courtès) writes:
> Noah Lavine <address@hidden> skribis:
>
>> 1. Alternate a lists of field names and values. The example becomes
>>   (set-field p (person-address address-city) "Düsseldorf" (age) 32)
>
> I prefer this one.  Perhaps it could be called ‘set-fields’, even.
>
> However, generating the most optimal code may prove to be complicated.
> For instance, you’d want:
>
>   (set-fields p (person-address address-city) "Düsseldorf"
>                 (person-address address-street) "Bar")
>
> to expand to:
>
>   (set-person-address p
>                       (let ((a (person-address p)))
>                         (set-fields a (address-city) "Düsseldorf"
>                                       (address-street) "Bar")))
>
> But that would require knowledge of the relationship between
> ‘address-city’, ‘address-street’, and the underlying record type, etc.

I don't understand why such knowledge is needed, or why this is
difficult.  We have procedural macros.  Simply sort the field-name-paths
lexicographically, split the sorted paths into groups with the same car,
and recurse.  Am I missing something?

> Instead, I think I’ll add ‘record-copy’, similar to Racket’s
> ‘struct-copy’ [0], as Ian Price suggested on IRC.  We can do this
> because it turns out that our SRFI-9 records are now “Guile records”,
> and thus they have a run-time type descriptor that maps field names to
> their indices.
>
> The drawback compared to generated setters as above is that field lookup
> happens at run-time, which degrades performance and delays any error
> report to execution time.

The associated runtime cost of searching for fields within the RTDs will
make functional records too slow for many purposes.  To my mind, this is
absolutely unacceptable for a data type as fundamental as records.  We
need to make functional record update as fast as we possibly can.

Let's not make such a basic data structure slow out of laziness.  If you
don't want to implement this, I'd be glad to.

     Mark