Re: reduce/reduce error confusing declaration with subscription

[Luca]

Tom Lieber ha scritto:
> On Sat, Dec 27, 2008 at 9:02 AM, Luca <address@hidden> wrote:
>   
> > Tom Lieber ha scritto:
> >     
> > > I'm creating a parser for a C-like language, basing it on this ANSI C
> > > grammar:
> > >
> > >  http://www.lysator.liu.se/c/ANSI-C-grammar-y.html
> > >
> > > I would like to change the syntax for declaring variables so that
> > > instead of writing this:
> > >
> > >  int a[4], b[4];
> > >
> > > You write this:
> > >
> > >  int[4] a, b;
> > >       
> > Modify the grammar in the following way:
> >
> > declaration
> >   : declaration_specifiers ';'
> >   | declaration_specifiers init_declarator_list ';'
> >   | declaration_specifiers '[' constant_expression ']' init_declarator_list
> > ';'
> >   ;
> >
> > I have added the third production: "int[4] a, b;" is parsed without generate
> > conflicts in bison or syntax errors in the parser.
> >     
>
> Thanks, but that's not recursive (so I can't stack pointers and
> brackets like "int[4][4] a, b;"), and it's less general than I'd need
> for it to carry over to other places in the grammar like function
> definitions and another place I'll want it.
>   
Yeah it was only an idea, only a an hint! I simply suggest WHERE to 
modify the grammar without introducing conflicts, then you have to do it 
according to your purposes. Anyway the following productions are what 
you need:



declaration
        : declaration_specifiers ';'
        | declaration_specifiers init_declarator_list ';'
        | declaration_specifiers array_square init_declarator_list ';'
        ;
        
array_square
        :
        '[' constant_expression ']'
        |array_square '[' constant_expression ']'
        ;


brackets like "int[4][4] a, b;" are now allowed and correctly parsed! 
You can do the same with pointers! 

Once you understand where function declarations are managed, you can also fix them. 

>   
> > Anyway I think it is more convenient for you to rewrite a C-like grammar
> > subset rather than try to modify the ANSI C grammar according to your
> > purposes.
> >     
>
> The grammar I'm going for is very nearly C. This change, some
> additional places where you can put declarations, and removal of
> prototypes, structs, and enums are pretty much the only differences
> between this language and ANSI C.
>   
C grammar doesn't allow the following syntax:

int[4] a

so you have to introduce it in the grammar removing C standard syntax:

int a[4]

if you allow both the way you could have many problems:

  1. conflicts in bison (maybe)
  2. your parser will allow both the declaration, so it is hard to emit
     the right code

So I thought it was easiest for you to rewrite a grammar, because C 
grammar isn't easy to understand if you never used tools like bison.
> Are you saying there is an easier way to structure a grammar this
> complex than the way the ANSI C one does (order of operations by
> nesting)? That seems to be the only special thing about that grammar
> compared to all the calculator language tutorials floating about,
> which use %left and %prec, which I've had less luck expanding into a
> full language.
>   
I always wrote grammar by myself rather than modify standard grammars; 
in this way I can understand very well all the problems. Of course, this 
is a time expensive way.
As you can read in the "red dragon", it is better to use %left, %prec 
and similar keyword rather than grammar rules, because in the latter way 
the parser has many states.

Luca