[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