Recommendation of a parser generator

[Francois Pinard]

[Fortepianissimo]

> I read from Charming Python column that SPARK is *very* slow (it uses
> Earley algorithm) (2)

We use SPARK in production and are satisfied with it.

SPARK can be very slow, indeed, if the grammar is ill conditioned[1], but
then, most other parsers will likely not accept such grammars anyway.  In
our experience so far, for "reasonable" grammars, and source files which may
be long, without being huge, SPARK is quite usable in practice.

One co-worker told me about a big application which run for hours, and rely
on more than thirty parameter files, each being a few pages long.  There are
a few different syntax for these parameter files, one being particularily
recursive and complex.  Using SPARK for analysing all these parameter files
added 15 seconds to the whole process, nothing worth the slighest complain.

--------------------
[1] What is an "ill conditioned" grammar?  This is a fuzzy concept, but I
might say that it is one that makes SPARK slow! :-).  I have some experience
with Bison (or YACC) parsing, which accumulated over the years.  So, I
merely write for SPARK grammars a bit like I would have written them for
Bison, but without being overly cautious or concerned about whether Bison
would be happy with my grammars, or not.  The result is usually workable.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard