Made some progress after lots of head scratching and re-reading the antlr
book:
1. I saw somewhere on a popular antlr web page that syntactic predicates
could only appear at the beginning of an alternative, this is inaccurate, in
fact my problem is solved by adding a predicate at the beginning of a ( )*
subrule (see below)
2. I found the "methodology" I was looking for, simply add a global
backtrack=true option, parse a few inputs that you suspect are trouble
makers and look at the parse tree which shows the backtracking in green &
red - much much easier for me to figure things out that way for recursive
errors.
Still not too sure about the performance impact of my predicate, but
hopefully looking at the parse tree for some complex inputs should give me
an indication since apparently it also shows the predicate evaluations in
green or red?
Refactoring seems at least as attractive but much harder to do right, and
without ending up with a useless AST.
Congratulations on the antlrworks tool, it is a life saver for inexperienced
grammar designers like me!
------------------------------------
program : callExpression ( ',' callExpression )*;
callExpression
: primaryExpression
| 'call' primaryExpression ( ( ',' primaryExpression )=> ','
primaryExpression )*
;
primaryExpression
: '(' callExpression ')'
| ID
;
--
View this message in context:
http://antlr.1301665.n2.nabble.com/Understanding-non-LL-errors-tp7027459p7029627.html
Sent from the ANTLR mailing list archive at Nabble.com.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
"il-antlr-interest" group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
