Re: SVG export - how might you add classes for all graphical objects?

[David Kastrup]

Aaron Hill <lilypond@hillvisions.com> 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