Issue 3639: tuplet of a single chord gives a syntax error

Issue 3639: tuplet of a single chord gives a syntax error


First replaces a fair bit of open/closed function argument
differentiation (before numbers/postevents) with greedy operator
priorities since otherwise the reparsing of chords/repeats gets ugly.

Consists of commits:

Issue 3639/2: allow chords in optional arguments


Issue 3639/1: allow \repeat in optional arguments


Eliminate closed argument lists before UNSIGNED and durations


Remove closed expressions before postevents and negative numbers

[Keith, 2013-11-02 22:34:51]

I have been reading, slowly absorbing this and the patch for issue 3618, and see
no problems so far.

I see now that the challenge is not so much determining that \repeat... is not a
duration for 
  \tuplet 6/4 \repeat tremolo 3 {g8 b}
but in collecting enough information to let ly:music? determine that \repeat...
is in fact music, should anyone write a function that has an optional argument
of type music (which I did write and which does now work).

I think this repairs all the realistic cases, where  {\relative <c' e g c>4 } is
the limit of what I considered realistic.

[dak, 2013-11-03 07:31:24]

On 2013/11/02 22:34:51, Keith wrote:
> I have been reading, slowly absorbing this and the patch for issue 3618, and
see
> no problems so far.
> 
> I see now that the challenge is not so much determining that \repeat... is not
a
> duration for 
>   \tuplet 6/4 \repeat tremolo 3 {g8 b}
> but in collecting enough information to let ly:music? determine that
\repeat...
> is in fact music, should anyone write a function that has an optional argument
> of type music (which I did write and which does now work).
> 
> I think this repairs all the realistic cases, where  {\relative <c' e g c>4 }
is
> the limit of what I considered realistic.

The current parser is quite distasteful (even after issue 3618 which at least
brought some logic and consistency into the rules rather than muddling around
until stuff works approximately).  At some point of time, one of two things
needs to be done

a) it must be verified whether it's not possible to switch out an already seen
lookahead token from the parser in the cases of reduction that are involved,
possibly by generating a particular parser family different from LALR(1).  The
main problem is that if the lookahead token causes a state transition rather
than just a reduction, that state transition is not likely undoable without
messing with the parser tables.  If the pushback can include the lookahead
token, most complications go away completely.  The parser can then just parse a
music/scheme function, and push back a *_IDENTIFIER after looking at the
resulting value type and/or check against argument predicates while within an
argument list.

b) a separate parser is instantiated for parsing function arguments, keeping the
lookahead needed for that away from the main parser.  But at the current point
of time, parser setup and destruction are likely too expensive to make that
desirable.

So in the end it will likely be some case of a) but that likely means that one
cannot treat the parser as a pure blackbox anymore, and it is conceivable that
future Bison versions will then cause trouble.

At any rate, thanks for looking at this.  It throws water on my "I guess it is
pretty safe to say that the only one who will review this particular patch is
myself." theory, but that's rather an advantage.