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 - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
