Urs Liska <address@hidden> writes:
I can store variables with symbol-list? names like so:
\version "2.19.80"
my.note.one = { c'4 }
my.note.two = { d'2 }
{
\my.note.one
\my.note.two
\my.note.one
}
It is also possible to store functions in such variables:
my.function =
#(define-music-function ()()
#{ c'4 #})
However, it is not possible to *call* the function like retrieving the
value above:
{
\my.function
}
yields "warning: ignoring non-music expression".
But I can do
{
#(#{ \my.function #})
}
Or $#{ \my.function #} but ugh.
My impression is that "\my.function" by itself retrieves the value,
i.e. the stored function, rather than applying it, while the last
example goes around some corners to actually doing what I want.
http://lilypond.org/doc/v2.19/Documentation/changes/index.html
Association list elements could previously be assigned values
individually (for example, paper variables like
system-system-spacing.basic-distance). They may now be also
referenced in this manner, as with
\paper {
\void \displayScheme \system-system-spacing.basic-distance
}
In combination with the previously mentioned changes, this allows
setting and referencing pseudovariables like violin.1.
I would like to find a smoother syntax to invoking functions like this
because I'd like to explore the possibility to create a namespace of
functions like \mylib.function-one, \mylib.function-two etc. But it
would only make sense if there's a really easy end-user syntax, and to
get there I'd have to first understand what is actually happening (in
the parser?) when \my.function is encountered.
I'd not expect it to be. Functions require some lookahead for being
differentiated properly in the parser (which is why we have music,
event, and scheme functions in the parser represented separately) and
the dotted syntax already burns that lookahead for its own parsing.
So don't expect it to work for invoking stuff.