Re: Music functions and #

[Erik Sandberg]

On Wednesday 20 July 2005 12.31, Han-Wen Nienhuys wrote:
> 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?

because it was an ugly hack, which nobody should apply. But, OK, it's 
attached. For no apparent reason, the patch
- allows music functions on \score and \layout blocks etc.
- is to 2_6 branch

The unused music_function_params nonterminal can be used to compress all
MUSIC_FUNCTION*_MUSIC_MUSIC into one token, and all other
MUSIC_FUNCTION*_MUSIC into another token. This would also make it possible to 
define music functions with an arbitrary number of non-music arguments, if 
that's followed by one or two music arguments. The remaining three required 
tokens are:
MUSIC_FUNCTION
MUSIC_FUNCTION_SCM
MUSIC_FUNCTION_SCM_SCM

> 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

Why can't we use MUSIC_FUNCTION_MUSIC and do ly:pitch? type-checking of the 
argument in Scheme?


If we can accept to limit the number of parameters, and we want to keep the # 
enforcement for strings & numbers, then this grammar WBN:

param:
 Music
 | full_markup
 | embedded_scm
 | string
;

Generic_prefix_music_scm:
 MUSIC_FUNCTION_0
 | MUSIC_FUNCTION_1 param
 | MUSIC_FUNCTION_2 param param
 | MUSIC_FUNCTION_3 param param param
 | MUSIC_FUNCTION_4 param param param param
 | MUSIC_FUNCTION_5 param param param param param
;

This also allows strings without leading #:s. It can't be made this clean if 
we allow DIGIT tokens in param, since in that case, c 4 can be interpreted 
either as Music DIGIT or as Music.

Erik

foo.diff
Description: Text Data