Comment #5 on issue 2018 by d...@gnu.org: Patch: parser.yy: allow
postevents in function arguments in general
http://code.google.com/p/lilypond/issues/detail?id=2018#c5
parser.yy: allow postevents in function arguments in general
This change is on top of the dev/syntax branch still in review. It removes
the "polymorphism" of music functions used explicitly as events.
The previous behavior was such that trailing arguments of kind ly:music?
were parsed as postevents instead of music, so that \tweak had a chance to
be implemented as a music function. This concept has become increasingly
fishy when ly:music? predicates where treated just like any old Scheme
predicate. Event functions (and music functions used as events) have not
inherited the new power of music function argument lists. Doing that with
something akin to the previous semantics would have required a large amount
of code duplication since one can't easily replicate a complex _recursive_
grammar while exchanging a core element.
This patch sidesteps the issue by just allowing both postevents and normal
music as function arguments for both music and event functions.
It passes the regtests, but there are consequences:
a) a music function can't figure out whether it is used in a postevent or
a music event setting by looking at the type of music argument it
receives. That type is orthogonal from how its return value gets used.
b) a music function might receive postevents where previously syntax
errors occured.
To be fair: most music functions were not bothering checking whether they
might be employed in postevent settings anyway, so it is not like this adds
a fundamentally new class of surprises.
I am still putting it out for separate review.
http://codereview.appspot.com/5339043
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
