lilypond-user
[Top][All Lists]
Advanced

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

Re: Understanding symbol-list? variable names


From: David Kastrup
Subject: Re: Understanding symbol-list? variable names
Date: Fri, 08 Jun 2018 12:43:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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.

-- 
David Kastrup



reply via email to

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