[antlr-interest] translation of $x references in v3.0

[Loring Craymer]

Ter--

I think the right answer is "It's about time that that particular defect was
fixed!"  However, that will make it harder to port existing ANTLR 2 apps to
ANTLR 3 (at least the Byzantine ones).  I'd suggest either having a flag for
ANTLR 2 compatibility on this or putting the suffix (and prefix--I prefer
prefixes to suffixes, but ANTLR 2 uses suffixes) under user control.

I gather that you are considering $ as the prefix character.  Not a good
choice in general--that would make it hard to have a BASIC target or any of
the UNIX shell scripting languages--although it does fit the Java/C++/C#
targets.  In fact, I'd vote against having more than one special character
for attributes in actions:  the only feature it provides the user is to
allow duplicate use of names and it complicates the translation mechanism
for the ANTLR backend developer.

Come to think of it, I would suggest considering 

@id = ID

Instead of  id = ID in your example.

--Loring

> -----Original Message-----
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Terence Parr
> Sent: Sunday, May 01, 2005 11:01 AM
> To: 'ANTLR Interest'
> Subject: [antlr-interest] translation of $x references in v3.0
> 
> Howdy,
> 
> I'm neck deep in the action translation at the moment; mostly
> refactoring and adding unit tests after speaking with John Mitchell
> yesterday at length.  After he smacked me around a little, I am
> convinced that I need to make some changes.  One is that we will use $x
> to refer to the stuff you're used to like parameters, return values,
> token labels, and rule labels; @x.y will refer to the new dynamic
> attribute stuff that you've been hearing about.  John and I agreed that
> a separate symbol is justified as the dynamic attributes are so
> different than the regular attributes.
> 
> Anyway, on to simple $x references.  One of the things that drives me
> nuts in 2.x is that sometimes you can forget the #x or $x and have it
> still get through ANTLR to compile and run...but #x, for example, is
> different than x!  Ack!  This kind of bug has trapped me for hours
> sometimes.
> 
> My proposal is that all labels and simple attributes like parameters
> are generated with a prefix or something so that you cannot
> accidentally reference them in an action.  This helps me track which
> return values you access, for example, which helps me generate better
> code.  If nobody references a rule return value, I won't generate code
> for it. :)
> 
> So if you had:
> 
> a[String s, int x] returns [float y]
>    : id=ID f=field {s, x, y, id, f.z;}
>    ;
> field returns [int z]
>    : ...
>    ;
> 
> you'd get compilation errors on s, x, y, id, and f.  You need to do
> 
> a[String s, int x] returns [float y]
>    : id=ID f=field {$s, $x, $y, $id, $f.z;}
>    ;
> 
> Note that multiple return values require that I build a struct or
> simple class to hold the values so s and x do not even exist as simple
> variable references.
> 
> Anybody care to comment?
> 
> Ter
> I've posted this to one of the blogs:
> http://www.antlr.org/blog/antlr3/rewrite.tml
> --
> CS Professor & Grad Director, University of San Francisco
> Creator, ANTLR Parser Generator, http://www.antlr.org
> Cofounder, http://www.jguru.com