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

Reply via email to