2. As currently formulated, it's not obvious to me that with this
modification the parser is guaranteed to terminate: although the
"expected case" is obviously that the amount of text "consumed" by
the looping construction should increase at each iteration, it should
be easy to create a grammar that yields success if the prior
iteration failed and vice versa, resulting in an infinite loop.
Presumably this could be fixed trivially by adding a hard-coded
restriction that the amount of text consumed actually does increase
with each iteration - e.g., use 'cur != -1 && len(cur) > len(prev)'
as the predicate of the 'while' loop.
Very interesting point, and I believe you are correct. I forgot to
consider the use of the ! operation in PEGS, and it's impact.
Well, in some grammars, the base case of a left recursion may not
consume any input. From my C grammar for Rats!
variant generic DirectAbstractDeclarator =
<FixedArray> DirectAbstractDeclarator "[":Symbol
AssignmentExpression? void:"]":Symbol
/ <VariableArray> DirectAbstractDeclarator "[":Symbol
VariableLength void:"]":Symbol
/ <Function> DirectAbstractDeclarator "(":Symbol
ParameterTypeList? void:")":Symbol
/ <Parenthesized> void:"(":Symbol AttributedAbstractDeclarator
void:")":Symbol
/ <Empty> null
;
The last alternative does not touch the input and just returns a null
value, which is the desired behavior for direct abstract declarators.
So, Bryan, your condition is too restrictive. Any suggestions?
Robert
_______________________________________________
PEG mailing list
PEG@lists.csail.mit.edu
https://lists.csail.mit.edu/mailman/listinfo/peg
