[antlr-interest] Literal - ID clash resolution

Junkman j at junkwallah.org
Tue Sep 14 11:04:03 PDT 2010


I'd guess the common first stab would be to have '=' as a distinct token
and elevate ID into a parsing symbol:

EQUAL: '=';
id: (ID | EQUAL) ;
option: optionName=id EQUAL STRING ;

It might become bit more interesting if you also need to make optionName
optional.

But maybe you could rewind the stack a bit, and reconsider if you really
want/need '=' as a valid identifier?

J

On 9/14/2010 10:15 AM, Bill Andersen wrote:
> Folks
> 
> I'm having a small problem.   Not that I can't solve it myself but it's one of those things for which:
> 
> a) I'm sure there exists a good stock solution, and
> 
> b) Google is especially poorly suited to find in a search
> 
> Here it is.  I have rules in the grammar for my DSL that have '=' as a literal appearing them.  Like this
> 
> option
>   : optionName=ID '=' STRING
>   ;
> 
> The DSL parses a language specification and that specification can define reserved words, one of which (in my test case) is '='.  This creates a problem: The DSL grammar must recognize '=' as an instance of identifier (ID - I'm using ANTLRWorks default lexer rule template, slightly modified, for now) but it can't recognize '=' as such because it's already a literal used in the DSL grammar.
> 
> Can anyone tell me what the best way to deal with this is?
> 
> If my explanation doesn't make sense (seems mine often don't for some reason) I'll be glad to post the whole grammar, but I don't think that's necessary.
> 
> 	.bill
> 
> 
> 
> 
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> 



More information about the antlr-interest mailing list