Issue 8: prioritized choice isn't properly applied to ambiguity at the lexer level
Project Member Reported by jhaber...@gmail.com, Jan 31, 2009
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
In my opinion

  s -> "X" / .foo=/[A-Z]/;

should be equivalent to

s -> "X" | .foo=/[A-WZ]/;

or

s -> "X" | .foo=/[A-Z] ~X/;

however le ~ operator is not defined yet (I've seen you plan using it in your
sketch/lua.gzl).
Feb 2, 2009
#2 manu....@gmail.com
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
Project Member #3 jhaber...@gmail.com
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.