[antlr-interest] Tricky vector constructor syntax

Jim Idle jimi at temporal-wave.com
Wed Jul 20 19:09:21 PDT 2005


Ah the sympathy pours out.
 
1) If this is under your control, use something other than <> as your delimiters.
2) The problem is that you are trying to use < as both a binary operator and a specified of components.
 
The only good way to deal with this (IMO, there might be other ways) is to extend your expression rule for '<' something like this:
 
lt_array : OPLT  (  (gtExpr ((COMMA gtExpr (COMMA gtExpr)?)? OPGT)?) 
  | (OPEQUAL ltExpr)
 );
 
So that your first pass is just producing a syntactically valid tree. Your second parse will walk the tree and check the semantics, such that you will look for an expression bounded by < and >. Then it all falls out pretty easily unless your precedence requirements make the tree rewrite a bit more complicated.
 
Actually, I will be interested in comments from others on this one. 
 
Jim
 
PS: I guess you now know what I am doing back on this list Mr. Youngman.
 

________________________________

From: antlr-interest-bounces at antlr.org on behalf of Richard Matthias
Sent: Sun 7/17/2005 2:10 PM
To: 'ANTLR Interest'
Subject: [antlr-interest] Tricky vector constructor syntax



Hi all,

I'm trying to write a parser for a scripting language used in an online game.
The language is predictably very C-like with a few twists, most of which are
quite benign, but one is really twisting my melon.

The language supports vectors and quaternions as data types and they have
provided syntax for constructing instances of these types that make it just a
little bit tricky to parse. For example:-

vector v = <4.0 , 1.2, 0>;

Of course that's just an initializer, the same angle bracket syntax can be
used in expressions and each of the three elements of the vector can of
course be expressions also. A quaternion is for the sake of parsing just the
same except it has four components.

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 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?

I commented out some other stuff so at least without the production in
question the grammar compiles without warnings to give a fighting chance! And
the lexer isn't complete yet so it won't produce the right tokens. Oh and
please don't ridicule my choice of token names too much :)

Regards

Richard




More information about the antlr-interest mailing list