[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Functional record “setters”
From: |
Ludovic Courtès |
Subject: |
Re: Functional record “setters” |
Date: |
Tue, 10 Apr 2012 16:27:50 +0200 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.93 (gnu/linux) |
Hello Mark,
Mark H Weaver <address@hidden> skribis:
> 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?
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’.
- Functional record “setters”, Ludovic Courtès, 2012/04/08
- Re: Functional record “setters”, Andy Wingo, 2012/04/09
- Re: Functional record “setters”, Ludovic Courtès, 2012/04/09
- Re: Functional record “setters”, Noah Lavine, 2012/04/09
- Re: Functional record “setters”, Ludovic Courtès, 2012/04/10
- Re: Functional record “setters”, Mark H Weaver, 2012/04/10
- Re: Functional record “setters”,
Ludovic Courtès <=
- Re: Functional record “setters”, Noah Lavine, 2012/04/10
- Re: Functional record “setters”, Mark H Weaver, 2012/04/10