| Issue 8: | prioritized choice isn't properly applied to ambiguity at the lexer level | |
| 1 person starred this issue and may be notified of changes. | Back to list |
This grammar should work fine with prioritized choice: s -> "X" / .foo=/[A-Z]/; However it complains with the following message: gzlc: compiler/intfa_combine.lua:65: Can't build DFA inside s, because terminals X and foo conflict The problem is that although Gazelle applies the given priority when choosing between rule paths, it doesn't know how to use priority to resolve lexer-level ambiguity. This should be fixed. I have no idea how hard this will be, but it should be fixed for 0.5.
Feb 2, 2009
#1
manu....@gmail.com
Feb 2, 2009
Contribution for a test-case : ----- expression -> (keyword | escapedvarname) / varname; // question: what are the associativity rules for '|' and '/' keyword -> "keyword"; escapedvarname -> "!" varname ; varname -> .name=/[a-z]+/; ----- I expect "keyword" to match as keyword, except if it comes after a '!'.
Feb 6, 2009
Yes, I agree with your comment about how this should work. Your test case will definitely demonstrate the proper behavior once this works correctly. However I think that in general this will not be the preferred way to deal with reserved words or keywords. The reason is that for most languages, reserved words cannot be variable names, regardless of the context. Consider: stmt -> "default" = value / var "=" value | "if" var "then" stmt; var -> /[a-z]+/; value -> /[0-9]+/; With this grammar, Gazelle would let you write things like: then=9 if if then then=6 ...because none of these things are ambiguous to Gazelle. But most languages don't let you do this (I believe FORTRAN is a notable example). So I think that in *general* this won't be the preferred way to deal with keywords. I think you'll want to define your varnames to have all the keywords specifically negated. |