David Kastrup <d...@gnu.org> writes: > Han-Wen Nienhuys <hanw...@gmail.com> writes: > >> On Thu, Aug 30, 2012 at 9:21 AM, David Kastrup <d...@gnu.org> wrote: >>>> Is there a complete proposal of what is on the drawing board? Barring >>>> that, is there a list of (perceived) problems in the current >>>> syntax/parser? >>> >>> The possible values for music following a skipped optional argument are >>> constrained to music parseable without lookahead because the decision >> >> I had to let this sink in for a bit, since I had completely missed >> that a patch doing optional music arguments had went in. Had I noticed >> in time, I probably would have complained (and we might have ended up >> in a flamewar). > > It was a matter of "what's good for the goose, should be good for the > gander". The existing hardwired LilyPond syntax used a variety of > optional arguments (partly skipped explicitly using \default, partly > left out like with \relative { c' }). Bringing the preexisting syntax > within the scope of music functions meant making Scheme programmers > stop being second-class citizens who have to take what they are fed.
As one example for an analogous use of optional arguments, consider \tweak Accidental #'color #red cis4 \tweak has always been a music function. Being able to use a syntax fairly analogous to that of \override makes things simple and straightforward for the user. You don't want to write \default in place of Accidental for every use without a grob qualification. And you don't want to have him remember different function names for each argument list variation. Of course this means that _compiling_ LilyPond into Scheme rather than interpreting it is not feasible when using #{ ... #} inside of functions. If this becomes really important one day, one can use trace compiling techniques: one compiles a version corresponding to the _current_ argument values while keeping track of the preconditions on the values corresponding to every syntactical decision taken. As long as the preconditions for the taken syntactical decisions are met on the next call, one uses the precompiled Scheme equivalent of the passage in LilyPond syntax. Otherwise, one repeats the process by calling the parser on the LilyPond version again. It is likely that 99% of all #{ ... #} constructs are not syntactically polymorphic, at least not intentionally so, so this technique should usually be low-overhead. On the other hand, the LilyPond parser is not exactly inefficient, either. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel