Hello Mark, Mark H Weaver <m...@netris.org> skribis:
> l...@gnu.org (Ludovic Courtès) writes: >> Noah Lavine <noah.b.lav...@gmail.com> 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’.
