[antlr-interest] Tail ambiguity

[Jim Idle]

It might be easiest to allow the mix in your parser, then throw them out
in semantic analysis. If you must throw it out in the actual parser then
allow both syntactically but in the component, create a rule scope which
flags which type is seen, then as you pick up another element, you can
check that it is of the same type and error out if it isn't.

Your ambiguity here is because rValue allows either rule, but both rules
contain LiteralExpression. One way or another, you need to rework that.

Hope that helps,

Jim

-----Original Message-----
From: antlr-interest-bounces at antlr.org
[mailto:antlr-interest-bounces at antlr.org] On Behalf Of Laurie Harper
Sent: Friday, May 18, 2007 2:36 PM
To: antlr-interest at antlr.org
Subject: [antlr-interest] Tail ambiguity

I'm trying to match a sequence of literal text interspersed with 
expression, where the expression can take either of two forms but can't 
be mixed. For example, 'a ${b} c ${d}' and 'a #{b} c #{d}' are legal, 
but 'a ${b} c #{d}' is not.

The problem is, I get an ambiguity warning I'm not sure how to get rid
of...

warning(200): ElSpecParser.g:41:4: Decision can match input such as 
"LiteralExpression EOF" using multiple alternatives: 1, 2
As a result, alternative(s) 2 were disabled for that input
w

Here's the relevant rule set:

rValue
	: (rValueComponent1)+ EOF
	| (rValueComponent2)+ EOF
	;

rValueComponent1
	: DOLLAR LCURLY expression RCURLY
	| LiteralExpression
	;

rValueComponent2
	: HASH LCURLY expression RCURLY
	| LiteralExpression
	;

The solution would be easy if mixed expression types were allowed :-/ 
Any suggestions?

L.