[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Music functions and #

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

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:

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 -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]