[antlr-interest] Advice on effective expr parsing

Ruslan Zasukhin sunshine at public.kherson.ua
Tue Aug 27 23:21:38 PDT 2002


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/ 



More information about the antlr-interest mailing list