David, On Fri, Jul 20, 2012 at 12:38 AM, David Kastrup <[email protected]> wrote:
> David Nalesnik <[email protected]> writes: > > > David, > > > > Why does this have to be a list? Why not just make it two > > separate > > arguments? > > > > If, for whatever reason, you really really really have this > > information > > in a two-element list called whatever, you can still write > > > > \once \alterBroken "Staff.BarLine" #'color #@whatever > > > > It certainly makes sense to use multiple arguments instead of a list > > for a music function that applies an override to a breakable item like > > a clef, since there are only two pieces to consider. However, the > > function is designed to apply to spanners as well, and these of course > > may have more than two pieces (e.g., SystemStartBar). I know it’s > > possible to have music functions with optional arguments, but are they > > able to accept an indeterminate number of arguments, one for each > > potential spanner sibling? > > No. > OK--so it makes sense to keep the list structure for the override in the \alterBroken function (if it in fact the function ought to accept both spanners and breakable items, which seems natural to me). > > > Regarding optional arguments: I’ve been experimenting, and I’ve hit > > several stumbling blocks. In the following (very contrived) example, > > I expect that both key signatures will be green. Both are when all > > arguments are present. When the optional argument is omitted, both > > should again be green because (scheme? arg2) still returns #t. > > Instead, both key signatures disappear. I don’t understand this > > behavior. > > > > test = > > #(define-music-function (parser location property arg1 arg2) > > (symbol? scheme? (scheme?)) > > An optional argument can be skipped only if there is some place in the > argument list where it can go. So in final position, optional arguments > are indistinguishable from mandatory arguments (actually not quite, > since they make preceding optional arguments also mandatory). You can, > however, still explicitly skip them by writing \default in the actual > argument list, like commands like \key and \mark let you do. > Ah, OK! So (for the record) writing \test #'color #blue \default works perfectly with the test function. And \test #'color #@(list green red) does too. > scheme? is a catchall predicate. It will gladly also take a music > expression. If you want a predicate that doesn't, write > (define (nomusic? x) (not (ly:music? x))) > and use that. It will then throw an error in this case instead of > setting the color to a key signature. > Seems so simple! > > My second quandary is the fact that (scheme? arg2) returns #t when > > arg2 is omitted, so it appears useless as a criterion for whether an > > optional argument is there or not.. (I’ve chosen scheme? as my > > predicate so the generalized function can accept a wide variety of > > data types.) > > scheme? always returns #t. At the current point of time, the only > argument predicates specially coded into the parser are ly:pitch? and > ly:duration? so they don't mix with scheme? syntactically. This will at > some point of time get removed as well. It is just somewhat tricky to > do. > > The advantage of not special-casing argument predicates is that you can > write predicates markup-or-music? or number-or-markup? and similar, and > they will work fine. It is just pitches and durations that have been > somewhat resistant against this unification. > Thanks very much for your explanations. This is much clearer to me now. -David
_______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
