> -----Original Message----- > From: [email protected] [mailto:antlr-interest- > [email protected]] On Behalf Of Geoffrey Romer > Sent: Tuesday, January 04, 2011 12:33 PM > To: antlr-interest > Cc: [email protected] > Subject: [antlr-interest] Multiple-target parsers, and extending > without overriding > > Hi- > > I'm new to ANTLR, and I'm trying to evaluate its suitability for a > project I'm working on. I'd appreciate help with a few questions: > > - What is the status of C++ support? The wiki indicates that C++ > support is coming "later in 2008", but this is obviously out of date.
Compile the C output as C++, keep custom code and actions entirely out of the parser and produce AST outputs. > > - One goal of the project is to provide cross-platform parsing and > unparsing support, i.e. to generate parsers and unparsers in multiple > target languages (primarily C++ and Java) from a single representation > of the grammar. As far as I can see, the only way to accomplish this in > ANTLR is to provide a grammar with AST output type which uses only > rewrite rules and AST operators (and, for unparsing, a tree grammar > with template output type), with no target-language code at all. Actually I use source code control for this. Start with a base definition of all your grammars without any actions, then branch to specific targets and add any target specific code. > However, I'm not sure this is feasible; many ANTLR features (e.g. > attributes and predicates, custom error handling) and techniques (e.g. > implementing case insensitivity or keywords-as-identifiers) require use > of a specific target language. Is this approach workable? Are there > better options I'm overlooking? You keep all such code outside the grammar and within your application code. There are few differences if you do that. Also use: id: ID | KEYWORD1 | KEYWORD2 ... etc; And not comparison code on ID to workout keywords. > > - Another goal of the project is to provide a unified parsing framework > for a family of closely related but distinct languages (specifically, > SQL dialects). You and everyone remotely interested in SQL ;) > We want to be able to express the language grammars in > terms of an inheritance hierarchy, where each language (other than the > base) is specified in terms of its differences from the parent > language. This seems like a natural fit for ANTLR's support for > composite grammars, but I see two drawbacks with that approach: first, SQL dialects are not really compatible enough to do that. > the languages may differ in both lexical structure and syntax; since > combined grammars cannot inherit from other combined grammars, this > seems to imply that we'd need to maintain separate, parallel > hierarchies of lexer and parser grammars, which are combined only in > the leaves. Is there a cleaner solution? Second, the composition > mechanism doesn't seem to support extending a grammar with new > productions; only overriding existing productions. Yes. Source code control is a better option here. Especially if you use one that is good at branches such as perforce. Jim 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
