[Lilypond-auto] Issue 3618 in lilypond: Optional pitch/duration arguments don't work in longer argument lists.

[lilypond]

Status: Started
Owner: address@hidden
Labels: Type-Defect

New issue 3618 by address@hidden: Optional pitch/duration arguments don't work  
in longer argument lists.
http://code.google.com/p/lilypond/issues/detail?id=3618

zap =
#(define-music-function (parser location dur a b)
  ((ly:pitch?) (scheme?) ly:music?)
  #{ #})

{ \zap { } }

throws an error:
/tmp/bla.ly:6:8: error: syntax error, unexpected '{', expecting  
TONICNAME_PITCH or NOTENAME_PITCH or PITCH_IDENTIFIER
{ \zap
       { } }

and the same using ly:duration? instead of ly:pitch? gives
/tmp/bla.ly:6:8: error: syntax error, unexpected '{', expecting \default
{ \zap
       { } }

In either case, the reaction seems rather uncalled for.  When using the  
predicate list? instead (which also does not accept the given music  
expression), the code compiles as expected, skipping both optional  
arguments and accepting the music argument.

Pitches and durations are currently parsed using special predicates  
hardwired in the parser and work using expression priorities.  I've tried  
debugging this problem somewhat, but it would appear that getting it right  
and maintaining it with the current approach is juggling too many variables.

Note that the first error complains about expecting one of the pitch  
starters (as if the argument was not optional after all), while the second  
error complains about expecting \default here (as if the argument needed  
explicit skipping).  The difference may or may not boil down to the  
difference between closed and non-closed music expressions (note that { }  
is perfect for either), but in effect, it looks like we are juggling too  
many things at once here in the parser.  Note also that _without_ the final  
ly:music? argument, we have the argument list of \key and that works  
reasonably well (though the use case is somewhat different).

I've not been successful in my initial attempts of exorcising this problem  
while maintaining EXPECT_PITCH and EXPECT_DURATION predicates, so I'll  
throw out the latter.  It will also remove one remaining inconsistency in  
argument list parsing, and then we have a single mechanism (which is bad  
enough) to debug rather than the current mixture of predicate- and  
priority-based parsing.

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings