Aaron Hill <[email protected]> writes: > On 2021-06-29 1:20 pm, David Kastrup wrote: >>> %%%% >>> \version "2.22.0" >>> SvgAddClassName = >>> #(lambda (ctxt) >>> (define (add-class-name grob) >>> (let* ((attribs (ly:grob-property grob 'output-attributes '())) >>> (class (ly:assoc-get 'class attribs '())) >>> (name (grob::name grob))) >>> (set! class (if (null? class) name (format #f "~a ~a" class >>> name))) >>> (set! attribs (assoc-set! attribs 'class class)) >>> (ly:grob-set-property! grob 'output-attributes attribs))) >>> (make-engraver >>> (acknowledgers >>> ((grob-interface engraver grob source) >>> (add-class-name grob))))) >> That assoc-set! looks like a stinker. Doesn't it mess with shared >> data >> structures? > > Hrm... would it be better to explicitly alist-copy the result from > ly:assoc-get? Actually, I guess you could do: > > ;;;; > (alist-cons 'class ... (alist-delete 'class attribs)) > ;;;;
Either that or not even bother about deleting the other entry. > ...since the SRFI says that alist-delete does not modify the original > structure, only that it might return an alist with a common tail. > > And on this point, should LilyPond provide an ly:assoc-set to pair > with ly:assoc-get that avoids potential issues with shared structures? I am not sure that we'd want our own modifiers for basic data structures. Though there may be a point in unifying hash tables, association lists, vectors into a common data structure and provide caching accessors for that. I mean, stuff like notename languages and drum tables and so are already an awkward mixture. -- David Kastrup
