Re: music macros?

[Nicolas Sceaux]

Han-Wen Nienhuys <address@hidden> writes:

> OK, so we create all music expressions/events as "Music promises",
> which expand into Music objects via some function as soon as they are
> inspected, but have \relative deal with music-promises directly?
>
> I think there should be a fool-proof (forced from the C++ side) way to
> make sure that all Music objects are instantiated in a 'delayed' way.
>
> Nicolas, what do you think?   I think that, in a sense, \relative
> would be analogous to a Scheme macro, and the rest would be like
> function calls.
>
> Hmm, maybe we should even take the distinction to the extreme: have
> both music functions and music macros. Nicolas?

This music macro / music function issue is interesting.

But I don't figure out what would look like (internally) the arguments
of a music macro. Will they be like today's music objects, but with some
extra types of objects like MusicFunction (with procedure and argument
properties for instance), MusicIdentifier (with variable name and value
properties), etc?

What is the idea then for \relative?  If it is made a music macro, it
will walk through its music argument, and adjust the octave of
NoteEvents (which would have been parsed as if they had absolute
octaves)?

I'm all in favor of music macros that can manipulate their unexpanded
music arguments (by unexpanded I mean: where music identifiers are not
replaced by their value, and music functions not applied.)

(wow, it took me one hour to write this shity answer, what a brain!:)

nicolas