[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

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’?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]