Hi Harm,
Am 13.10.2018 um 01:18 schrieb Thomas Morley:
Hi Urs,
Am Sa., 13. Okt. 2018 um 00:00 Uhr schrieb Urs Liska <li...@openlilylib.org>:
%% Not sure if needed, though, better be paranoid and work on a copy of
%% default-script-alist to avoid possible bleed-over.
#(define my-script-alist default-script-alist)
Except that this doesn't *create* a copy but only a reference, isn't it?
So your changes to my-script-alist also affect default-script-alist.
Well, if I add
#(pretty-print
(lset-difference
equal?
my-script-alist
default-script-alist))
at the end of my file, I get:
(("path"
(avoid-slur . inside)
(padding . 0.5)
(stencil . #<procedure my-path-stil (grob)>)
(side-relative-direction . -1))
("polygon"
(avoid-slur . inside)
(padding . 0.5)
(stencil . #<procedure my-polygon-stil (grob)>)
(side-relative-direction . -1)))
If default script-alist would be changed as well, then the result should be '().
Or am I thinking wrongly?
Ah, no, that's correct. But it's not because of your initial "copy" with
define. See
\version "2.19.82"
#(define list-a '((one . 1)(two . 2)))
#(define list-clone list-a)
#(define new-list '())
#(set! list-clone (assoc-set! list-a 'three 3))
#(set! new-list (assoc-set! list-a 'three 3))
#(define new-list-b (assoc-set! list-a 'three 3))
#(display list-a)#(newline)
#(display list-clone)#(newline)
#(display new-list)#(newline)
#(display new-list-b)
You'll notice that list-clone, new-list, and new-list-b are all the same
in the end. If I'm not mistaken it's because assoc-set! is the point
where the copy is actually made. So you could either 'define' the new
list somewhere or probably initialize it to an empty list before
performing the assoc-set!
This also indicates that using assoc-set is potentially inefficient when
performed numerous times. It would seem better to first check if the key
is already present and if necessary cons the new element to the
beginning. But I may be mistaken because I don't know how assoc-set!
*really* works internally, maybe it's more optimized than I'd think.
Best
Urs
Cheers,
Harm
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user