howdy! On Jan 18, 2010, at 8:21 PM, Terence Parr wrote:
hiya! added http://www.antlr.org/wiki/display/~admin/ANTLR+v4+plans so we can plan ahead and track a wish list.* 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.Every time I look at the tool code I cringe, to be honest. It's huge (for what it does) and at times I can't help thinking that it21k lines ain't *that* bad really. it's a pretty dang complicated problem, especially with composites etc... it *is* dark and scary inside though :(
fair enough on the size. still it's hard to adapt to different needs, and i guess that's what counts.
* I have some important new features such as the better expression grammar stuff that would be inconvenient to implement in the current code base.And incremental parsing ;)Hmm...incr parsing is easy. incr lexing is not.
consider it a "nice to have" feature request ;)
- Change to make it OSGi-friendly (the tool I mean).I just scanned the pages for OSGi. uh, what the hell is it? ;) What would you need?
http://en.wikipedia.org/wiki/OSGi has a pretty good overview :)osgi is basically a framework for handling code modularity, allowing for a very dynamic environment for code bundles (basically jars). it's pretty strict on classloading, because it versions the packages and generally you cannot expect context classloaders do to what you would normally think they'd do. in general it would be easy to create the necessary manifest headers to the antlr jars, and ST would only need minimal changes, i assume (basically injecting the correct classloader) for what i would like to do pretty soon, it would be awesome to let antlr find its codegen templates dynamically, even if contributed by different bundles.
cheers, -k -- Kay Röpke
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev
