LALR ambiguity resolution

I recently wrapped my head around LALR to write a LALR generator , and I am trying to build a java or C # -style grammar for it (which starts here ).

I know it's an effort to write a parser generator, like reinventing the wheel for example (why not use Antlr?), But my goal is to load a hobby subsystem that can compile itself, depending on a third party toolchain. My problem, though not with the generator, but with the grammar.

I am working on reducing / reducing ambiguities with operators and expressions.

I know how to resolve certain types of ambiguities such as dangling-else, but these few are not intuitive to me and they puzzled me.

What's the best way to solve these problems? Also, is there a prototyping tool that I can use to visualize the solution? Or if I go back to square and try to implement a GLR parser generator for grammar?

These statements are legal:

Generic.List<int> myVar1 = x + 4, myVar2; // stmt -> var-decl ;
                                          // var-decl -> type-name var-decl-list

t = 99;                           // simple-stmt -> assign

i++;                              // simple-stmt -> incr-decr
                                  // incr-decr -> primary-expr ++

json.deserialize<list<int>>(obj); // simple-stmt -> call
                                  // call -> primary-expr ( params )
                                  // ...  -> primary-expr . basic-name ( params )
                                  // ...  -> basic-name . basic-name ( params )

      

        
        
        
      

    

This is how it is configured:

basic-name : ident < type-list >
           | ident

nested-name : nested-name . basic-name
            | basic-name

basic-type : int | bool | ...

type-name : nested-name
          | basic-type

stmt : var-decl ;
     | simple-stmt ;
     | ...

var-decl : type-name var-decl-list

var-decl-list : var-decl-list , var-init
              | var-init

var-init : ident assign-op expression
         | ident

simple-stmt : assign
            | call
            | incr-decr

expr : assign-expr

assign-expr : assign
            | cond-expr

assign : unary-expr assign-op expr

...
rel-expr : rel-expr < shift-expr
         ...
         | shift-expr

...
unary-expr : unary-op primary-expr
           | primary-expr

unary-op : + - ! ~ ++ --  // Prefix operators
         | ( type-name )  // Conversion operator

primary-expr : call
             | primary-expr . basic-name
             | primary-expr ++
             | ( expr )
             ...
             | basic-name

call : primary-expr ( params )

incr-decr : primary-expr ++
          | -- primary-expr
          | ...

      

        
        
        
      

    

So when the parser is expecting a statement, the core of the element set * LR (k) is method-body -> { * stmts-opt }

, and the complete element given for the state looks something like this:

method-body -> { * stmts-opt }
stmts-opt -> * stmts
stmts-opt -> *
stmts -> * stmts stmt
stmt -> * var-decl ;
stmt -> * simple-stmt ;
var-decl -> * type-name var-decl-list
simple-stmt -> * assign
simple-stmt -> * call
simple-stmt -> * incr-decr
type-name -> * nested-name
type-name -> * basic-type
nested-name -> * nested-name . basic-name
nested-name -> * basic-name
basic-name -> * ident < type-list >
basic-name -> * ident
assign -> * unary-expr assign-op expr
unary-expr -> * unary-op primary-expr
unary-expr -> * primary-expr
unary-op -> * ( typename )
unary-op -> * ! | ~ | ...
primary-expr -> * call
primary-expr -> * primary-expr . basic-name
primary-expr -> * primary-expr ++
primary-expr -> * basic-name
primary-expr -> * ( expr )
call -> * primary-expr ( params )
incr-decr -> * primary-expr ++
...

      

        
        
        
      

    

When the identifier is shifted, the following state is:

basic-name -> ident *
basic-name -> ident * < type-list >

      

        
        
        
      

    

which is disassembled or reduced, and brings the following state:

nested-name -> basic-name *
primary-expr -> basic-name *

      

        
        
        
      

    

Potential conflict. In the parent state, lookaheads do not help as there is a dot in nested-name

and primary-expr

. Oh, okay, let's try decreasing by nested name:

type-name -> nested-name *
nested-name -> nested-name * . basic-name

      

        
        
        
      

    

Can't see anything here ... Now, how about shortening to primary-expr

:

unary-expr -> primary-expr *
primary-expr -> primary-expr * . basic-name
primary-expr -> primary-expr * ++
call -> primary-expr * ( params )
incr-decr -> primary-expr * ++
...

      

        
        
        
      

    

Now when we shift ++ we get:

primary-expr -> primary-expr ++ *
incr-decr -> primary-expr ++ *

      

        
        
        
      

    

... another conflict with decreasing decreasing.

Try moving (

instead ident

:

primary-expr -> ( * expr )
unary-op -> ( * type-name )
expr -> * assign-expr
assign-expr -> * assign
assign-expr -> * cond-expr
assign -> * unary-expr assign-op expr
unary-expr -> * unary-op primary-expr
unary-expr -> * primary-expr
unary-op -> * ( typename )
unary-op -> * ! | ~ | ...
primary-expr -> * call
primary-expr -> * primary-expr . basic-name
primary-expr -> * primary-expr ++
primary-expr -> * basic-name
primary-expr -> * ( expr )
call -> * primary-expr ( params )
cond-expr -> * ...
...
rel-expr -> * rel-expr < shift-expr
rel-expr -> * shift-expr
...
type-name -> * nested-name
type-name -> * basic-type
nested-name -> * nested-name . basic-name
nested-name -> * basic-name
basic-name -> * ident < type-list >
basic-name -> * ident

      

        
        
        
      

    

Same problems when you push ident

or (

stack.

These are just the ones I ran into. Since basic-name

takes precedence over rel-expr

, I'm guessing something x < n

would seem to be interpreted as basic-name -> ident < type-list *

errors if it were actually a relational expression.

My brain has reached the point where I can really help.