Comment #2 on issue 935 by d...@gnu.org: Enhancement: optional arguments in
music functions
http://code.google.com/p/lilypond/issues/detail?id=935
Before investing unnecessary work here: is the bounty offer still good or
should it be removed from the issue report?
There are some situations where optional arguments would be feasible. The
optional argument could, quite in contrast to how Scheme does it, not be
the last argument, and it would need to differ in type from the following
argument. For example, an optional Scheme argument before a music argument
should work. An optional pitch before a music argument would require the
music argument to be "closed", delimited. And so on.
Grinding out a reasonable set of combinations that will make it through
bison without shift/reduce or reduce/reduce conflicts will be considerable
work.
And one has to note that things like
\myfunction \withoption #... { }
are already possible: \withoption will just be a music function integrating
#... into the following music expression in a manner that \myfunction,
taking just a single music argument, will be able to use.
So the basic usability boils down to being able to differentiate things like
\myfunction #... { } from \myfunction { }.
That's limited. It could likely suffice to turn both forms of \relative
into a single music function. And a few other things. But it would really
cover only a limited set of combinations, and it will take work coaxing
those into the grammar (I don't expect the resulting changes to be overly
complex, but they'll take a lot of experimentation).
So I'd probably take this on only if there is sufficient interest in the
kind of functionality I just sketched. Probably the syntax would be
something like
relative = #(define-music-function (parser location pitch music)
((ly:pitch? (ly:make-pitch 0 0 0))
ly:music?)
...
Namely for optional signature parts, you specify the default when the
argument is not given.
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
