:
> hier_id
>| method_call
>| paren_expr
> ;
> paren_expr:
> '(' expression ')'
> ;
> method_call:
> paren_expr '.' YYID paren_expr
> ;
> hier_id :
> YYID
>| hier_id '.' YYID
> ;
>
>
> At
description, it sounds like you
> can do this:
> 1+3.YYID(7)
> but what would this mean ?
> Henrik
>
> On Sunday 27 March 2005 21.37, Soumitra Kumar wrote:
> > %token YYID
> > %%
> > expression : hier_id
> >
> > | method_cal
%token YYID
%%
expression : hier_id
| method_call
/* unary and secondary expression follows.
*/
;
method_call : expression '.' YYID '(' expression ')'
;
hier_id : YYID
| hier_id '.' YYID
;
How to resolve the shift/reduce conflict? Please help.
-So
For the grammar:
%token YYID YYDOT
%%
identifier : hier_id
;
hier_id : simple_id
| hier_id opt_select YYDOT simple_id
;
opt_select :
| opt_select '[' expr ']'
;
simple_id : YYID ;
expr : hier_id
| function_call
;
function_call : expr YYDOT Y
Henrik,
I understand that grammar is ambiguous.
In case of big grammars, it gets difficult to find out
the rules causing the conflicts.
While creating the lookahead set, if bison can
annotate the rules too, it would be helpful.
So, if I get the following output (rule no after a
lookahead symbol)
Following is a sample grammar. There is one r/r
conflict.
% cat test.y
%token YYID YYDOT
%%
identifier : hier_id
;
hier_id : simple_id
| hier_id opt_select YYDOT simple_id
;
opt_select :
| opt_select '[' expr ']'
;
simple_id : YYID ;
expr : hier_id
All,
I am willing to write a parser for systemverilog.
Following is the LRM.
http://www.eda.org/sv/SystemVerilog_3.1a.pdf
I am looking for some advice.
. Should I take the bnf as it is and start resolving
the conflicts, or rewrite the rules myself.
. In case of reduce/reduce conflicts, multiple
