Re: Music functions and #

[Han-Wen Nienhuys]

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.
>
> Are there any plans to do anything about this?
>
> 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