Re: music macros?

[Erik Sandberg]

Citerar Han-Wen Nienhuys <address@hidden>:

> Erik Sandberg wrote:
> > Yes, just represent those commands as music functions internally. E.g., 
> > \transpose creates a MusicFunction expression, with a list of two pitches
> and 
> > one Music as its 'elements (or 'arguments, I haven't decided yet), and 
> > 'to-music-callback is set to ly:music-transpose (or rather, to a wrapper 
> > around that function).
> 
> 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?

The way I view it, only functions and variables would need to be "promises".

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

Interesting idea, but I don't understand it fully (how would \relative
instantiate music, if the C++ code prohibits that?).

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

Sounds like a sound idea. Apart from \relative, it would be nice to also have
\score, \include, \header etc. as macros.

In this case, IWBN if a ly file always was a single music expression in a
sense,
so one would in principle be allowed to place braces around the top-level ly
file, like:

{ foo = { c d e }
\score {
  \foo
  \header {...}
}
}

I this kind of syntax would make it possible to improve the language in the
future; I'm thinking of making a \lambda music function (not macro) possible.

There's the question of whether function parameters should have some kind of
parentheses around them. It _might_ be possible to introduce \lambda without
requiring this, there is however a risk of dirt in the grammar.

> Regarding the \parallelMusic: we should make sure that noone uses
> 
>   \parallelMusic #'(A B)
> 
> to define identifiers inside music expressions. We could just leave this 
> aspect undocumented, or put a big warning sign that this will change in 
> the near future.

Well, we could just even hard-code the command into the parser for now
(prohibiting people from using it).

It would be nice if we could have a discussion on post-3.0 syntax before
releasing 2.8: This would increase the possibilities to do some wise
intermediate syntax changes for 2.8, similar to the 1.6->1.8->2.0 chord syntax
changes. (seems that you already have done this with \score syntax, but we
might need more, depending on the plans for 3.0)

Erik