Werner LEMBERG <w...@gnu.org> writes:
>> Here is an example (where I use the Scheme equivalent of
>> assignment): [...]
>
> Interesting. Note that
>
> foo = \relative c' { c d e f g }
> \bookpart {
> \foo
> }
>
> foo = \relative c'' { g f e d c }
> \bookpart {
> \foo
> }
>
> fortunately works as expected (this is, different notes in different
> \bookparts), while
>
> #(define notecolor blue)
> \bookpart {
> \score {
> { \override NoteHead.color = #(lambda (grob) notecolor)
> c1
> }
> }
> }
>
> #(define notecolor red)
> \bookpart {
> \score {
> { \override NoteHead.color = #(lambda (grob) notecolor)
> c1
> }
> }
> }
>
> gives a red notehead both times. So I think that your comparison is
> not completely valid, since lilypond's `variables' are obviously
> expanded at a different time than Scheme assignments.
No, they aren't. This is not due to a difference between LilyPond and
Scheme. If you override with #notecolor you'll again get two different
colors. But #(lambda (grob) notecolor) is called at iteration time, and
at that time the second assignment to notecolor has already happened.
> Is this documented somewhere?
That iteration and parsing happen at different times? It's not all that
surprising. If we write
\score { ...
\midi ...
\layout ...
}
then we get two instances of iteration for the music starting the
score. It's not all that surprising that it is only read in once.
We don't allow assignments inside of music expressions either, and again
the reason is not as much that it wouldn't be possible to allow them
there, but rather that people would be surprised that "reassigning" a
variable inside of music will affect previous uses of it and not be in
any conceivable way synchronized with the "flow" of music.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
