lilypond-devel
[Top][All Lists]

## Re: Music functions and #

 From: Han-Wen Nienhuys Subject: Re: Music functions and # Date: Wed, 20 Jul 2005 12:31:07 +0200 User-agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513)

Erik Sandberg wrote:

Hi,


I'm a bit frustrated that one have to add a # before strings and numbers, when calling a music function. This makes it impossible to do implement commands such as \bar in Scheme, since the argument to \bar has no # before it. Problems: a) It increases the size of parser.yy (\bar could otherwise be defined in ly/*)
b) It makes it impossible to tweak \bar without re-compiling lilypond

c) It can potentially make users confused: It might be hard to remember in which situations you're supposed to add a # before a parameter to a music command.



One way could be to force the usage of # before all constants, i.e. forbid string and DIGIT in commands, and use embedded_scm instead. This would be a very consistent solution, with a more clean grammar as a result, but OTOH users may get frustrated that we require them to write more characters.


I'm actually more fond of enforcing # everywhere. Having parameters without # introduces a lot of unnecessary hairiness. For example, 4.0 sometimes is a float, sometimes it is a dotted quarter duration followed by a zero. # gives us neatly defined semantics at the expense of a single character. However, being able to drop tokens and rules from the parser (MUSIC_FUNCTION_x) is also an asset.


Another way is to allow the usage of non-SCM expressions as parameters to music functions. I did some experiments on parser.yy, in particular I replaced all embedded_scm parameters with music_function_param, where music_function_param is defined as identifier_init but with Music, post_event and number_expression removed.
>

No shift/reduce conflicts were introduced, and it made it possible to write a clone of \bar as a Scheme function. In addition, it made it possibile to reduce the number of MUSIC_FUNCTION* tokens to 5.

Why is this not done? May I write a patch?


Why don't you post the patch so we can see the implications?


In general it would be nice to have more genericity in the parser. I think that if we do separate MUSIC_FUNCTION_PITCH for example, then we softcode the following rules

- \transposition
- \key
- \transpose
- \relative

--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen