« Return to Thread: Functional record “setters”
Re: Functional record “setters”
by Ludovic Courtès-3
::
Rate this Message:
Hello Mark,
Mark H Weaver <mhw@...> skribis:
> ludo@... (Ludovic Courtès) writes:
>> Noah Lavine <noah.b.lavine@...> 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?
Yes: nothing forces you to prefix names with ‘address-’ here.
>> 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.
Agreed. This is why the patch I posted take a purely syntactical
approach.
Though we must keep in mind that calling these setters involves a
‘make-struct’ call, which is already expensive. Does anyone have
figures on the relative cost of (say) a function call compared to a
small heap allocation?
> 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.
Implement what? The proposed ‘set-fields’?
Thanks,
Ludo’.
Mark H Weaver <mhw@...> skribis:
> ludo@... (Ludovic Courtès) writes:
>> Noah Lavine <noah.b.lavine@...> 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?
Yes: nothing forces you to prefix names with ‘address-’ here.
>> 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.
Agreed. This is why the patch I posted take a purely syntactical
approach.
Though we must keep in mind that calling these setters involves a
‘make-struct’ call, which is already expensive. Does anyone have
figures on the relative cost of (say) a function call compared to a
small heap allocation?
> 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.
Implement what? The proposed ‘set-fields’?
Thanks,
Ludo’.
« Return to Thread: Functional record “setters”
| Free embeddable forum powered by Nabble | Forum Help |
