[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: # and $ (was Re: metronome-mark-alignment)

From: David Kastrup
Subject: Re: # and $ (was Re: metronome-mark-alignment)
Date: Wed, 15 Jan 2020 02:18:01 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Aaron Hill <address@hidden> writes:

> On 2020-01-14 2:39 pm, David Kastrup wrote:
>> Ok, let me try again.
>> # and $ differ in several respects.  # inserts Scheme constructs in
>> places where LilyPond can decide how they fit into its syntax without
>> looking at their value first.  In that case, evaluation of those Scheme
>> expressions is done at the time the expression is being actually used
>> which tends to be what one expects.  In contrast, $ can be used in
>> places where the value of the expression will have an impact on just
>> how
>> LilyPond will put them into context.  For example, a $ expression
>> evaluating to a duration may be combined with a preceding pitch to form
>> a note, while having it evaluate to another pitch in the same place
>> will
>> form a separate note.
>> This syntactic flexibility may lead to the expression getting
>> evaluated
>> at an unexpectedly early point of time, namely when LilyPond needs to
>> know its type in order to decide that it does not actually combine with
>> the preceding expression.
> Many thanks for the clearer picture.
> Would you be able to clarify how # and $ differ with regards to making
> copies of music?  Consider:

# does no processing of its own, $ creates a copy when given music.

> %%%%
> \version "2.19.83"
> notes = \fixed c' { g4 fis8 g a2 }
> test = #(define-music-function (which music) (symbol? ly:music?)
>   (define (red-notes music)
>     (if (memq 'note-event (ly:music-property music 'types))
>       (set! (ly:music-property music 'tweaks) '((color 1 0 0))))
>     music)
>   (case which
>     ((hash) #{ {
>         #music % will be red
>         $music % will NOT be red
>         \musicMap #red-notes #music % modifies music
>         #music % will be red
>         $music % will be red
>       } #})
>     ((dollar) #{ {
>         #music % will NOT be red
>         $music % will NOT be red
>         \musicMap #red-notes $music % modifies a copy of music
>         #music % will NOT be red
>         $music % will NOT be red
>       } #})))
> \test hash \notes
> \test dollar \notes
> %%%%
> The resulting behavior largely makes sense with one exception:
> Why does the use of \musicMap against #music in the first \test not
> have an impact on \notes itself?  Is there an implicit copy of \notes
> when invoking the \test function that goes beyond the use of # and $
> within?

No, it's that \notes is identical to $notes (apart from the syntax) in
that it creates a copy.  So whenever you write \something and do
something with it, whatever you do with it will not affect the original
stuff stored in the Scheme variable something .  Basically the idea is
that you get a copy whenever you reference a variable, but the music
passed around in expressions and from one function to another does not
get copied unless you need more than one version of it.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]