[antlr-interest] simple novice grammar question

[Greg Gimler]

Mark,

     Thanks for the quick reply.


>From: Mark Lentczner <markl at glyphic.com>
>Reply-To: antlr-interest at yahoogroups.com
>To: antlr-interest at yahoogroups.com
>Subject: Re: [antlr-interest] simple novice grammar question
>Date: Tue, 25 May 2004 07:44:42 -0700
>
> > "(x>3)(y=='somestring')"  pass as a valid string when I would like it
> > to fail.
>Hmmmm, it doesn't pass with the grammar you supplied.  Are there
>perhaps other rules involved that you didn't list?  If startRule is
>used in any other rule, then it parsing for startRule will match the
>prefix of any string ("(x>3)") and just leave the rest unmatched with
>no error ("(y=='somestring')").  If this is the case, put in a
>debugging rule that isn't used by any other rule.  Top level rules have
>an implicit EOF match at the end which is what you need.

Adding this to the top level rule fixed the problem.  Thanks!

>
>
> > I've attached just the parser below...
>Your grammar was a bit too permissive.  Here is a clean up:
>
>startRule : filter ;
>filter    : LPAREN! bool_or RPAREN! ;
>bool_or   : bool_and  (OR^      bool_and)* ;
>bool_and  : bool_comp (AND^     bool_comp)* ;
>bool_comp : factor    (bool_op^ factor)? ;
>bool_op   : EQ | NEQ | LT | LTE | GT | GTE ;
>factor    : filter | IDENTIFIER | NUMBER | STRING ;

I tried using this and got an antlr compile error about the "bool_op^"

output:

filter.g:48:31: rule classDef trapped:
filter.g:48:31: unexpected token: ^
error: aborting grammar 'FilterParser' due to errors
Exiting due to errors.

I guess you can't have tree suffixes on rules, only tokens?

>
>Notes:
>1) Generally there is no need to make the LPAREN the head of the tree
>in the filter (or factor) rule.  The tree implicitly has the correct
>order of operations in it and doesn't need grouping operators.

Got rid of that.  Seems OK.

>2) bool_comp_seq served no purpose

Agreed.  I had mistakenly left that in as it was a rule earlier when I was 
debugging.  Thanks for pointing that out.

>3) bool_comp shouldn't have a * at the end - bool_op's generally aren't
>associative.  The question is what should "x < y < z" mean.  In
>languages where "x < y" returns true or false (such as Java or C++),
>then associative bool_ops would result in "x < y < z" being parsed as
>"(x < y) < z" which would result in a boolean value being used in a
>less than comparison.  This would hardly be what the programmer wants.
>Languages take one three tacks:
>    3a) let the programmer suffer, and boolean ops are associative like
>all ops (Java, C++)
>    3b) make bool ops non-associative so "x < y < z" generates a compile
>time error (Perl 5)
>    3c) support combining bool ops so "x < y < z" is the same as "(x < y)
>&& (y < z)" but only evaluating y once.  (Cobol, Perl 6)
>The last is nice, but harder to design into a language.
>4) The separate bool_op rule makes the grammar
>
>	- Mark
>
>Mark Lentczner
>markl at wheatfarm.org
>http://www.wheatfarm.org/
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
     antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/