[antlr-interest] enums in v4 ANTLR Java code generation considered useless

[Terence Parr]

On May 18, 2010, at 2:58 PM, Scott Stanchfield wrote:

> There are several advantages to enums:
> * there is a discrete set of values that can be used (no accidental
> 42's passed in when 42 isn't a token type)
> * the enum value can carry extra information
> * the enum values can override methods differently

These are all excellent advantages. I believe that these mostly apply when you're writing code, not generating. Just like the compiler generates integers underneath, if antlr is generating integers, it's probably okay.

> OH - one of the things that's clouding this is that you really don't
> need the numeric type identifers anymore. You can just have
> 
>  public enum TokenType {
>    IDENT, INT ...;
>  }
> 
> then in your match method:
> 
>  void match(TokenType type) {
>    if (LA(1).getType() == type) {
>        ...
>    }
>  }

The only problem is that match() lives up in the superclass in the library but the generated parser needs to define the enum.

I also have the problem that I need to merge token types from multiple grammars for grammar imports. This gets more competition with enum types without inheritance.

> 
> And you can use the types in a switch statement:
> 
>  switch(type) {
>    case INT:
>    case IDENT:
>    ...
>  }
> 
> No more magic numbers! Woohoo!

ANTLR already uses the labels when possible such as INT. If you use a literal in your grammar such as ';' in don't label it in the lexer, than I had no choice but to generate the integer token type or a weird label like TOKEN34.

Ter