|Compiler Tool with Error Recovery email@example.com (Julian Mensch) (2009-02-12)|
|Re: Compiler Tool with Error Recovery firstname.lastname@example.org (2009-02-14)|
|Re: Compiler Tool with Error Recovery email@example.com (Vladimir Makarov) (2009-02-17)|
|Re: Compiler Tool with Error Recovery firstname.lastname@example.org (Johannes) (2009-02-19)|
|Re: Compiler Tool with Error Recovery email@example.com (Julian Mensch) (2009-02-21)|
|Re: Compiler Tool with Error Recovery firstname.lastname@example.org (Bill Cox) (2009-02-25)|
|Date:||Thu, 19 Feb 2009 04:12:30 -0800 (PST)|
|Posted-Date:||19 Feb 2009 11:23:55 EST|
On Feb 12, 9:14 pm, Julian Mensch <jmen...@shaw.ca> wrote:
> I am hoping someone here can point me in the right direction
> on a compiler tool. I have an existing script language defined in
> a hacked version of ACCENT, but I am beginning to feel my
> needs exceed what ACCENT can provide and am thus considering
> porting my grammar to a different compiler tool. A primary
> difficulty here is error recovery, which ACCENT doesn't do at
Another possiblity is using ANTLR from <http://www.antlr.org>.
> My requirements are:
> * parse ambigious grammar like ACCENT and Elkhound, using
> either GLR, Earley or something similar.
I don't know ACCENT and Elkhound, but ANTLR can parse C++ which is
> * Generate C++ code, or C code that can be hacked into C++
> with macros, modifying the skeleton, etc. Does not need to
> generate a parser _class_; procedural code that is legal C++
> is fine.
It has a C target which is compatible with C++.
> * Good support for error recovery
Never used the error recovery, but I haven't seen users complain about
lack of it / wrong design.
> * Works with the FLEX lexical analyzer
Theoretically, ANTLR parsers require only input conforming to this
interfaceorg_1_1antlr_1_1runtime_1_1_token.html> (for C things may or
may not differ - ask the maintainer of the C target for details). I
haven't used FLEX so I don't know how hard it is to make its output
conform. A token-integer-mapping file is also necessary, but
sshouldn't pose much difficulty.
> * Free or reasonably inexpensive
> * Does not put license restrictions on the generated parser code
ANTLR is under a BSD license.
> * Ideally, provides for definable context objects the way ACCENT
I don't think that there is direct in-built support for that but the
general facilities should suffice (assuming I've correctly inferred
the meaning of the question).
> * Ideally, has a nice, readable source syntax like BNF for the
> sake of code maintenance, and to make porting from ACCENT
This is a more subjective question. At least I think ANTLR grammars
> * Not too steep learning curve, since I need to get the grammar
> ported in a weekend or two if it's going to be worthwhile.
Depends too much on your own expertise and what your requirements are
to say for sure, but most people get up to speed fast regarding the
> * Tested and in use tool on projects other than mine, because I
> don't want to port and be stopped by crippling parser bugs I
> don't have the skill to fix.
Active community, lots of bugs have been fixed over the development
from version 3.0 to 3.1.2 (soon to be released). Should be no problem
Return to the
Search the comp.compilers archives again.