[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