Very Computer

Hello, I am using GNU Bison for creating a parser for resource scripts.
These scripts should contain definitions for MENUs, BITMAPs, and so on.
There are constructors like in C++ for defining certain objects.
For defining rectangles it would be fine to have some kind of
overloading:

COOR (INT,INT)
RECT (INT,INT,INT,INT)
RECT (COOR,COOR)

I would like to to parse constructs like this:

RECT r1 = RECT (0,0,1023,767);

// or:

COOR c0 = COOR (0,0);
COOR c1 = COOR (1023,767);
RECT r1 = RECT (c0,c1);

For this I use the following grammar rules:

exp_int   -> NUM
           | ID

exp_coor -> COOR '(' exp_int ',' exp_int ')'
          | ID

exp_rect -> RECT '(' exp_int ',' exp_int ',' exp_int ',' exp_int ')'
            RECT '(' exp_coor ',' exp_coor ')'
          | ID

The problem is that exp_rect produces a reduce/reduce-conflict:

    exp_rect  ->  RECT '(' . exp_int ',' exp_int ',' exp_int ',' exp_int
')'
    exp_rect  ->  RECT '(' . exp_coor ',' exp_coor ')'

This is because exp_int and exp_coor both may result as an ID:

    exp_int   ->  TOK_ID .
    exp_coor  ->  TOK_ID .

I know the reason for this conflict, but how could one rewrite this
piece
of grammar without conflicts in a natural way?

I assume that the ID token means "IDentifier", so I think it can't be
reduced to exp_int which means "expression of type integer".
Rewritting the grammar like the following, it has no reduce/reduce
conflict :

%token  NUM
%token  ID
%token  COOR
%token  RECT

%start  exp_rect

%%
exp_int  : NUM

exp_coor : COOR '(' exp_int ',' exp_int ')'
         | ID

exp_rect : RECT '(' exp_int ',' exp_int ',' exp_int ',' exp_int ')'
         | RECT '(' exp_coor ',' exp_coor ')'
         | ID

--
Herve Couppe de Lahongrais (SEU)       | Eurocontrol Experimental Centre