[antlr-interest] Advice on effective expr parsing
Greg Lindholm
glindholm at yahoo.com
Wed Aug 28 07:54:48 PDT 2002
That doesn't solve the problem, it's still ambiguous.
If your goal is simply to distingish between an expr and a
list then all you need to do is make the COMMA manditory
by using a '+' instead of an '*'.
row_expr
: LPAREN row_list_element ( COMMA row_list_element )+ RPAREN
| row_list_element
;
--- Ruslan Zasukhin <sunshine at public.kherson.ua> wrote:
> on 8/28/02 3:38, Greg Lindholm at glindholm at yahoo.com wrote:
>
> Okay, Greg, I see your idea.
>
> But I'd like avoid merging of them. Why?
> Because other rules that call 'expr' and rules that call 'row_expr'.
>
> I did think that if parser can differ this 2 things, this is STRONGER
> parser, yes? Or I am wrong ?
>
> What about the next idea -- to use additional variable, and condition
> in
> action?
>
> row_expr
> { bool list = false; }
> : LPAREN e:row_list_element
> rest:( COMMA { list = true } row_list_element )* RPAREN
> {
> if( list == false ) // we have expr
> {
> ## = #rest;
> }
> else // we have list
> {
> ## = #e;
> }
> }
> ;
>
> > Ask yourself this; If the parser sees "LPAREN expr RPAREN" should
> > it match a "primary" or a "row_expr" ? Since the COMMA separated
> > list is optional and a row_list_element can be an expr, this is
> > ambiguous.
> >
> > The even more trivial example is that a row_expr can be an expr, so
> > how would the parser know which to match.
> >
> > My suggestion is to combine expr and row_expr together (eliminate
> > row_exp) adding the COMMA separated list to expr.
> > Then later during semantic analysis you could check for comma
> > separated expr lists and report errors if invalid in the context.
> >
> > Hope that helps.
> > Greg
>
> > --- Ruslan Zasukhin <sunshine at public.kherson.ua> wrote:
> >> Hi Guys,
> >>
> >> Assume I have the following rules in grammar.
> >> It is easy to note that rule row_expr has ambiguity between 1 and
> 2
> >> branches
> >> on LPAREN expr RPAREN
> >>
> >> -----------------------------------------------------------------
> >> expr
> >> : primary( (PLUS | MINUS) primary)*
> >> ;
> >>
> >> primary
> >> : LPAREN expr RPAREN
> >> | unsigned_value_specification
> >> | column_reference
> >> | set_function_specification
> >> | subquery
> >> | case_expression
> >> | cast_specification
> >> ;
> >>
> >> row_expr
> >> : LPAREN row_list_element ( COMMA row_list_element )*
> RPAREN
> >> | row_list_element
> >> ;
> >>
> >> row_list_element
> >> : expr
> >> | "null"
> >> | "default"
> >> ;
> >>
> >
>
----------------------------------------------------------------------
> >>
> >>
> >> Yes, using syntax predicate this can be handled as
> >>
> >> row_expr
> >> : (LPAREN row_list_element COMMA) =>
> >> LPAREN row_list_element ( COMMA row_list_element )*
> >> RPAREN
> >> | row_list_element
> >> ;
> >>
> >>
> >> But I afraid this is NOT effective way.
> >> Because expr in general case can be VERY LONG and COMPLEX.
> >>
> >> So I wonder does exists any "secret" "cool" trick to resolve this
> >> problem in
> >> row_expr ?
> >>
> >> What is the best way ?
>
> --
> Best regards,
> Ruslan Zasukhin [ I feel the need...the need for speed ]
> -------------------------------------------------------------
> e-mail: ruslan at paradigmasoft.com
> web: http://www.paradigmasoft.com
>
> To subscribe to the Valentina mail list
> send a letter to valentina-on at lists.macserve.net
> -------------------------------------------------------------
>
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
More information about the antlr-interest
mailing list