I also have doubts about the performance characteristics and the possibility of starting to rely on the target language to fill in gaps such as token numbering - we could get to the point where code generators cannot be built for more primitive languages because the schema is relying the language to automatically do things.
The generated code should be as primitive as possible, with the runtime being as maintainable and clear as possible while not sacrificing performance. Jim > -----Original Message----- > From: antlr-interest-boun...@antlr.org [mailto:antlr-interest- > boun...@antlr.org] On Behalf Of Terence Parr > Sent: Wednesday, May 19, 2010 11:35 AM > To: antlr-interest interest > Subject: Re: [antlr-interest] enums in v4 ANTLR Java code generation > considered useless > > > 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 > > List: http://www.antlr.org/mailman/listinfo/antlr-interest > Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your- > email-address List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
