Re: Music functions and #

[Han-Wen Nienhuys]

Erik Sandberg wrote:
> because it was an ugly hack, which nobody should apply. 

it also doesn't work, since you have to use apply to stitch lists of 
parameters together.

> The unused music_function_params nonterminal can be used to compress all
> MUSIC_FUNCTION*_MUSIC_MUSIC into one token, and all other

(nitpick: it's not a token, but a production rule. Of course there are 
still multiple tokens)

> 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

What would be the effect on error-reporting of the arbitrary 
number-of-arguments change?

> > 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?

it's possible, but you have to have extra error checking to catch things 
like

  \transpose { f } \lyrics { bar }  { ..victic-music.. }


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