Re: Music functions and #

[Erik Sandberg]

On Wednesday 20 July 2005 14.09, Han-Wen Nienhuys wrote:
> Erik Sandberg wrote:
> > 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)

We would both reduce the number of tokens and the number of production rules, 
as there is a 1-1 relation.

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

AFAIU, it would still be caught by the argument type-checking 
(type_check_proc). One would get the same kind of nice message as in
\applymusic #3
I.e.:
wrong type for argument N.  Expecting FOO.

> >>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.. }

What if we just define transpose using something like
transpose = #(def-music-function .. (ly:pitch? ly:pitch? ly:music?) .. )
?

I think this would catch the above with something like
wrong type for argument 1.  Expecting pitch.
which IMHO even is better than the current
Unexpected '{'

Erik