[antlr-interest] Tricky vector constructor syntax

Richard Matthias richard at exaflop.org
Mon Jul 18 17:28:41 PDT 2005


Thanks Nigel and Paul for taking a look at my problem. Of course I should
have included the original yacc grammar with my query for comparison so I've
done so here. I don't really understand LALR parsers that well but if you do
maybe you can gain some insight. I don't know if yacc produces any ambiguity
warnings/errors with that grammar as I couldn't get the cygwin copy of bison
I have installed to grok it.

I was considering Paul's suggestion of an expression branch that doesn't
include relational operators since it doesn't really make any sense to use
them inside the vector constructor as far as I'm concerned, but I did log
into the game and test it with this delightfully useless fragment which does
compile and run without error so another solution was required:-

        if (<3, 4, 0> == <3, 4, 4>5 >)
            llOwnerSay("true");
        else
            llOwnerSay("false");

Which yields "true" because the boolean results of relational operators are
rendered as integers (as in C) which are acceptable as components of a vector
(implicitly cast to float even though the language seems to require explicit
casting everywhere else, but anyway..)

Looking at the use of syntactic predicates in the sample grammars I thought
it would be nice in the vector initializer rule to say "if it looks like an
expression it's an expression" but then I realised that only works between
alts of the same rule and not in mutually recursive rule sets like the
expression system here. Thanks to Nigel's indentification of the ambiguity
being between the relationalExpression and postfixExpression (badly named I
know) rules, I tried setting the greedy option on the operator group of
relationalExpression. It suppressed the warning and when I riggged up enough
code to test the grammar in action, it does behave as expected.

relationalExpression
	: shiftExpression 
	  ( options { greedy=true;} 
	    : (LEFT_ANGLE^ | LESSTHAN_EQUALS^ | GREATER_EQUALS^ |
RIGHT_ANGLE^) shiftExpression 
	  )*
	;


I have a nasty feeling that after I've sent this email I'll find some case
under which it breaks down, but even a horrid example like:-

vector v = <1,2, 5>6 > > <1,2,3>;

Seems to parse as expected by examining the AST using AST.ToStringList().

Regards,

richard

>-----Original Message-----
>From: antlr-interest-bounces at antlr.org 
>[mailto:antlr-interest-bounces at antlr.org] On Behalf Of Paul Johnson
>Sent: 18 July 2005 07:46
>To: 'ANTLR Interest'
>Subject: Re: [antlr-interest] Tricky vector constructor syntax
>
>Nigel Sheridan-Smith wrote:
>>>-----Original Message-----
>>>From: antlr-interest-bounces at antlr.org [mailto:antlr-interest- 
>>>bounces at antlr.org] On Behalf Of Richard Matthias The grammar (which 
>>>I've attached) has an expression section shamelessly lifted from the 
>>>java.g sample grammar but altered slightly to match the 
>original yacc 
>>>grammar supplied by the makers of the game. For the moment
>
>Does the yacc grammar handle the vector init? If so, it would 
>be (very)interesting to see how they do it.
>
>>>I've
>>>placed a rule for just the vector at the same level as the other 
>>>constants (the last alt of the postfixExpression rule) and 
>even with a 
>>>syntactic predicate it still causes the same ambiguity warning. Does 
>>>this look right or should I try and shoehorn it in at the same level 
>>>as the < operator?
>
>At first sight, I'd say it's in the wrong place; an 
>initialiser isn't a postfix expression. It should have a very 
>low priority, which might fix your immediate problem by 
>itself. Look at a real C grammar; Tom Stockfisch's yacc 
>grammar is a good starting point.
>
>> What this means is that the following bits of code are ambiguous:
>> 
>> x = < 1, 1, 1 > 5 >;
>> 
>> Not sure how to solve this one, as I have trouble getting syntactic 
>> predicates in the optional alternatives right. Maybe someone 
>else can 
>> suggest an appropriate change?
>
>If you have to give your initialiser such a high priority, 
>then your answer may be to exclude relationals from the 
>expressions in the list. 
>You'll need two expression syntaxes: a normal one, and one 
>which excludes relationals; then you might have
>
>postfixExpression
>     ...
>     < expr_non_relational , expr_non_relational , 
>expr_non_relational >
>
>HTH
>
>Paul
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lsl.y
Type: application/octet-stream
Size: 14402 bytes
Desc: not available
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20050719/2f20fceb/lsl-0001.obj


More information about the antlr-interest mailing list