[antlr-interest] how can I handle special identifiers that are not reserved words?

[Peggy Fieland]

I used:

   identifier 
     | non_keywords;

but I wrote a program to generate the non_keywords,
using the (sorted)  ...TokenTypes.txt
file as input.  

I wrote it in c++.

Peggy
--- Costa Basil <costa_basil at yahoo.ca> wrote:

> Hi,
> 
> I have to write a parser (in c++) for a language
> containing commands with options, however, the
> options are not reserved words and they can be used
> as identifiers in some other commands. The lexer is
> handwritten in c++. 
> 
> For instance, I have:
> 
> command:
>  option1 = expression
> | option2 = expression
> | option3 = expression
> 
> option1, option2, option3 are identifiers (i.e. they
> begin with letter and they continue with letters or
> digits) and they are not reserved words.
> 
> How can I do this in antlr? The workarounds that I
> was thinking of are:
> 
> 1. Use semantic predicates:
> 
> option1 = expression1 becomes
> 
> {LT(1)->getText() == "option1"}? identifier "="
> expression
> 
> downside: if the semantic predicate is not used as
> the first condition in an alternative then antlr
> sets the semanticexception message that gets thrown
> in case the predicate is false to the text between
> the curly brackets which I find unacceptable (is
> there a way to control the message?).
> 
> Example of code generated:
>         match(TK_IDENTIFIER);
>         if (!(LT(1)->getText() == "OPTION1"))
>             throw
> antlr::SemanticException("LT(1)->getText() ==
> \"OPTION1\"");
> 
> 2. Treat option1, option2,, etc. as reserved words.
> Create a production:
> 
> id:
>  identifier 
> | option1
> | option2
> | ...
> and use this wherever an identifier is supposed to
> be used.
> 
> Downside: every time I have to add another option
> that is not a reserved word I have to remember to
> add it here as well.
> 
> My question to you guys: is there another way to do
> this? 
> 
> I was almost thinking it would have been nice if
> antlr supported token subtypes. For instance I could
> have specified option1 with the form:
> identifier::option1 where identifier is the main
> token and option1 is the subtype and then have the
> match function support this kind of syntactic
> construction by matching the main token and its
> subtype. 
> 
> Thanks,
> Costa
> 
> PS. Is there a way to search the mailing list
> archives? I couldn't find a search feature...
> 
> 
> 
> 
> 
> 
> 		
> ---------------------------------
> Enrich your life at Yahoo! Canada Finance