Re: music macros?

[Nicolas Sceaux]

Han-Wen Nienhuys <address@hidden> writes:

> I think that the parser should handle music expression
> arities, and assemble the right tree structures. I have the feeling
> we'll get into hairiness if we don't, and we would loose error
> handling and recovery that is now provided by bison. This means that
> we have to do the identifier lookup directly, otherwise we can't
> discover the arity of a music function, and generate the right tree.
> What we want to postpone is the application of said music function
> (ie. running the appropriate Scheme fragment).

I've not thought about that (the parser having to know the type of an
identifier). You're right.

If music identifiers are changed by their value before macros being
processed, it's not possible anymore to make a \relative macro:

  foo = { d' e' }
  \relative c' { c \foo f }

\relative's argument would be { c { c' e' } f } and would be turned
into absolute octave music: { c' { c'' e''' } f''' }.
Unless some hack is used to make \relative recognize when a music object
was introduced with a music identifier (e.g. with a music property, so
that \relative should skip it).

> just as an aside, changing relative to a macro has some compatibility
> caveats: currently we allow both
>
>    \relative { STUFF }
>
> and
>
>    \relative c'' { STUFF }
>
> if we make \relative generic, then this is no longer possible.

Right! Doh. (The mechanism behind hard coded \relative could be that of
a \relativeMusic macro, though).

> wouldn't it be better to do the "expansion" when we start
> iterating the expressions? Then we can have the unfold repeats for
> MIDI for free.

Good idea.

> BTW, looking at the parser, I see another option for deconstructing it
> further. It might be possible to add lexer-mode switches to the
> annotation of a music function.  Then we could also soft-code the
> definition of \lyrics, \lyricsto, \figures, etc.

Now, that would be cool!

nicolas