[Lilypond-auto] Issue 3723 in lilypond: Patch: Parser: make optional arguments compatible with lookahead

[lilypond]

Status: Started
Owner: address@hidden
Labels: Type-Enhancement Patch-new

New issue 3723 by address@hidden: Patch: Parser: make optional arguments  
compatible with lookahead
http://code.google.com/p/lilypond/issues/detail?id=3723

Parser: make optional arguments compatible with lookahead

Basically reimplementing the MYBACKUP and MYREPARSE macros based on an
experimentally verified understanding of the LALR(1) parser produced
by Bison, this makes it possible to greatly simplify the grammar while
making optional funciton arguments (and particularly the following
non-optional arguments even when optional arguments are being skipped)
behave much more predictable.

Further simplifications are feasible: this is a first pitch.  Consists
of the following commits in reverse order:


Adapt documentation for optional arguments now that lookahead is permissible


Parser: properly disambiguate pitches from music in function arguments

In many instances, function arguments were parsed greedily without
looking at the function argument predicates first.  This did not allow
using subsequent function arguments of type pitch and duration since
they were combined into one music expression.

Parser: remove command_element and command_event synonyms of tempo_event


Parser: remove pitch_arg and PITCH_ARG


Parser: inline a few "common" expressions occuring only once now


Remove all closed music expressions


Permit event functions to use a non-closed argument list.


Add location data to extra_tokens_ stack in lexer.


Parser: let MYREPARSE and MYBACKUP back up even in presence of lookahead

This implies that the lookahead token must not yet have made an impact
on the state stack other than causing the reduction of the current
rule, or switching the lookahead token while Bison is mulling it over
will cause trouble.

Since an LALR(1) works on the top of the stack, this can usually be
guaranteed.  The "Too much lookahead" message is not produced.  If
these constructs are misused, the parser should typically complain
about the replacement token being unexpected.

The advantage is the ability to vastly simplify syntax rules that up
to now have to avoid lookahead tokens with a lot of drudgework.

Move the extra_token mechanism out of the lexer proper

Calling lex->pop_extra_token explicitly in the parser's yylex function
makes things considerably more robust.  It also allows pushing and
popping the EOF condition, necessary for backing up right at the end
of a file, like with ##{ \relative { c d e f } #} where the music
expression is checked against being a pitch, and then is backed up.

http://codereview.appspot.com/41720043

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