[antlr-interest] Keyword for referencing the enclosing rule in rewrite scope?

[Sam Harwell]

That would imply that the following would be allowed, but it isn't:

rule
	:	(	ID
			-> ^(ID)
		)
		(	NUMBER
			-> ^(NUMBER rule)
		)?
	;

error 136: reference to rewrite element rule without reference on left
of ->

Also, you get an error 119 if you try to make a label whose name matches
another rule, like this:

rule
	:	ID
	; 

rule2
	:	ID
	; 

rule3
	:	rule=rule2 // error 119
	;

So the only thing $rule could ever mean inside a rewrite rule is the
enclosing rule, and the only thing rule could ever mean inside a rewrite
rule is a reference on the left of -> that is not the enclosing rule.

-----Original Message-----
From: Gavin Lambert [mailto:antlr at mirality.co.nz] 
Sent: Wednesday, August 13, 2008 3:26 PM
To: Sam Harwell; antlr-interest
Subject: Re: [antlr-interest] Keyword for referencing the enclosing rule
in rewrite scope?

At 07:03 14/08/2008, Sam Harwell wrote:
>As I mentioned before, this construct as it exists in v3.1 will 
>give a compile error even when a label reference is unambiguous 
>according to the language rules. The error's purpose is solely to 
>alert the user to the possibility they meant something other than 
>what they wrote (could be a warning?). To prevent the problem, I 
>propose adding a special keyword to consistently designate the 
>enclosing rule's label in the rewrite scope.

It's not '$rule' that's ambiguous, it's the 'rule' in the tree 
rewrite.  So the reference *is* ambiguous according to the 
language rules.

>rule
>:               (              ID
>                                 -> ^(ID)
>                 )
>                 (              NUMBER rule
>                                 ->            ^(NUMBER $rule 
> rule)
>                                 )?
>                 ;

If I recall a previous discussion on this correctly, ANTLR 
produces a warning and also different behaviour than what you 
might be expecting ('rule' is treated equivalent to '$rule' in 
that context, IIRC).

Adding a new keyword like you propose might be useful in other 
cases, but it still wouldn't remove this ambiguity.  As Ter said, 
the right thing to do here is to add a label to your use of 'rule' 
as a subrule and use that in the tree construction instead.