> 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’ , 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.