Citerar Han-Wen Nienhuys <[EMAIL PROTECTED]>:
> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
