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?
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?
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.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel