Re: Issue 3639: tuplet of a single chord gives a syntax error (issue 20320044)

[dak]

Reviewers: Keith,

Message:
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.

Description:
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

Please review this at https://codereview.appspot.com/20320044/

Affected files (+92, -81 lines):
  M lily/parser.yy