The only thing *really* causing headaches for the Visual Studio integration is the association of error handling to threads instead of to the grammar generator when it's actually a property of the latter.
Before rewriting the code, I think the following major issues affecting syntax should be covered so you know the new design will meet the needs: * Syntax for expression parsing * Support for ambiguous tree nodes (similar to backtracking=true, except it keeps all viable alts instead of just the first one) The design of the profiler and debugger grammar configurations concerns me because grammars that support debugging have to be derived from a different base class than regular grammars. I might be able to make this a non-issue for the CSharp3 target by adding grammar support directly to the .NET debugger in Visual Studio and a custom analyzer for the logs produced by the profiler. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Terence Parr Sent: Sunday, January 17, 2010 3:49 PM To: ANTLR-dev Dev Cc: Gerald Rosenberg; Graham Wideman; Jean Bovet; Ola Bini; Joey Hurst Subject: [antlr-dev] ANTLRv4? Hiya. I'm now ready to embark on ANTLR (and ANTLRWorks) code development after 2 years in book-writing mode. We've got an important decision to make: do I try to continue with the current ANTLR v3 source base or start from scratch heading to ANTLR v4? Here are some data points to consider: * I must reimplement ANTLR v3 in v3, just like I did recently for ST (yielding ST v4). Besides being untidy, important projects like eclipse cannot include ANTLR at the moment due to license restrictions on it's v2 dependency :( Jim Idle has graciously build a proper ANTLR parser, AST builder, and AST tree grammar that I can use to get us to v3. :) * While I tried to do as much re-factoring as possible while developing ANTLR v3, most of it was tactical. At some point, strategic re-factoring (rewriting whole sections or all) becomes necessary. For example, I literally had to jam grammar composition into the tool, leaving it fragile. It's becoming hard to fix things and add new features. A lot of the current features have been added while writing the first and second books. Doing so simultaneously was valuable from a feature and functionality point of view, but not from a code cleanliness point of view. * I have some important new features such as the better expression grammar stuff that would be inconvenient to implement in the current code base. * Trying to jam a new ANTLR front end into the existing semantics engine and grammar analysis engine might be challenging. It would be hard to get all of the various pieces to hook up properly. * Code generation. I learned a lot while building ANTLR v3's re-targetable code generation system; as a result, it's not exactly the cleanest thing in the world. I also would like to restructure the generated parsers. E.g., I'm going back to exception handling for backtracking since it is much cleaner and likely faster, as long as I reuse the same exception object during backtracking. targets without exception handling like C can continue to use the existing "if (failed) return" concept. I'd also like to manage my own arguments and return values stack so that rules predicated upon parameters don't fail during code generation (when I move a parameter reference outside of the defining function). Even if we stay with the exact same code generator and templates, all of you target developers will have some changes to make to keep in sync regardless. * The runtime library seems to be pretty good. I don't think I would change much of anything there except for efficiency stuff. With luck, a v4 or updated v3 version could also reuse most of the templates. I'd tried to avoid gratuitous changes. That said, I don't think that templates are the problem. It's always the library that people have to build in order to make a target and those are already done. perhaps target developers can voice their opinions here. * I have 8 months left on my sabbatical for full-time code development (i.e., no teaching duties). Sabbaticals come once every seven years. [Oh, feel free to start hating me now!] I suspect that I have about another year and a half or two years before I need to start writing again. First thing would probably be a v4 update for the definitive ANTLR reference guide. * STv4 was remarkably easy and fast to build using the existing unit tests and reference implementation (ST v3). There was a lot of cutting and pasting, but most importantly, there was no decision-making really. I knew exactly what I wanted to build. Deciding on features and functionality is always the hard part. coding is easy. I estimate it would take me six months to make a v4 ANTLR. I'd shoot for simply a better implementation of the current functionality set and then worry about the new features. The NFA->DFA conversion algorithm is the most difficult component, but one that I could reuse almost completely. So, let's open this up for discussion. What are the pros and cons of taking the six months to build ANTLR v4? What effect would it have on the project? are there some things that need to be fixed immediately? Would such changes get thrown out when I rebuild the front end (which we *must* do to remove the v2 dependency)? Are there changes I could make that would help other tool developers like Gerald's eclipse plug-in? I'd like to make it as easy as possible for people to integrate ANTLR stuff. ok, who's freaked out now? ;) Thanks for your thoughts in advance, Ter _______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev _______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev
