parrt

> why use a concrete syntax tree at all?

Do you mean instead of an AST? I find the syntax tree better for non-compiler applications like translators.

Thanks for the ptr. :) I just wish I had time to rewrite that book in ANTLR 4 (it's in ANTLR 3).

Howdy! It is definitely the case that most production languages use handbuilt parsers. In talking with these compiler developers, they are obsessed with control (speed, error reporting, ...) and want very specific data structures built during the parse. They also tend to use existing lexer infrastructure that is baked into their development environments. I commented more on this topic here: http://stackoverflow.com/questions/16503217/antlr-for-commer...

The thing to remember is that the vast majority of parsers out there are not for these production language compilers. Compare the number of people you know that have built parsers for a DSL, data, documents, or whatever to the number of people you know that built compilers. ANTLR's niche is for your everyday parsing needs. It generates fast ALL(*) parsers in a multitude of languages and accepts all grammars without complaint, with the minor constraint that it cannot handle indirect left recursion. (Direct left recursion as an expressions is totally okay.) For a speed shootout with other tools, see OOPSLA paper http://www.antlr.org/papers/allstar-techreport.pdf

Excellent discussion!

An interesting idea. Not sure anyone is working on that.

Interesting, though it is a framework very similar to previous work using Box combinations. Here, we don't require any work from a language expert. We simply sniff your project, and then make new files look like those. Handling a new language requires no coding.

A small followup to Jurgen's post. Python's indentation is meaningful so any change to it would mean we changed the program. In that sense, python is not a good target for this tool. Also, as a simple implementation expedient for this version, I assume that '\n' is not significant.

The hard part of building a code formatter by hand is coding all the formatting rules, not the parsing. All formatters are based upon parsers so that is a constant across them. Creating a grammar from exemplars is still an unsolved problem.

Yep. no definition of "good style". The tool simply makes new files look like the rest of your project.

I should add Adaptive LL(* ), ALL(* ), of ANTLR 4 to the mix here. It handles any grammar you give it and generates a correct parser except for one small caveat: no indirect left-recursion. It's the culimation of 25 years of focused effort to take LL-based parsing to the limit of power while maintaining simplicity and efficiency. See tool shootout in OOPSLA '14 paper I just presented http://www.antlr.org/papers/allstar-techreport.pdf Until we change the requirements of a parser generator, I'm done. :)