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