Re: Compiler Tool with Error Recovery

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
> all.


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
also ambiguous.


> * 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
interface <http://www.antlr.org/api/Java/
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
> does.


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
> easier


This is a more subjective question. At least I think ANTLR grammars
suffice here.


> * 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
basic/advanced features.


> * 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
here.


Best regards,
Johannes

Return to the comp.compilers page.
Search the comp.compilers archives again.