Re: [boost] Formal Review: The Spirit Parser Framework.

From: Dan Gohman (dgohman_at_[hidden])
Date: 2002-10-19 12:03:43

Here is my review of the Spirit library. I think Spirit should be
accepted.

I have several comments, many of which could be addressed with better
documentation. The documentation that is there is mostly good, but
there should be more.

In yacc, a common idiom is to use semantic actions like
{ $$ = new_foo_node($1, $3); } to build up a tree structure with my own
types, and it isn't clear how to do something like this with Spirit.
Short of having a page dedicated to porting from yacc, this specific
issue should be addressed.

I looked at Spirit's AST support, but for my purpose I would need to
translate Spirit's AST into an AST using my own types. It would be better
if I could construct this tree directly. Also, finding a typo in
ast_parse that prevented it from compiling as well as discovering that
none of the tree components have tests made me a bit shy.

Closures seemed to be more complicated that what I needed; the large
section in the documentation discussing closures as mechanisms for
accessing variables from an enclosing scope was distracting and made me
look for a simpler solution. Also, it wasn't clear how to control the
result value, the '$$' in yacc terms, of a parse using closures.

The brief mention of contexts in the documentation made them seem
promising, and while the documentation mentions that context is part of
the public API, it isn't documented. I dug into the source to figure
out what was needed and wrote my own context class. The result is code
that compiles but fails at runtime while trying to access an
uninitialized reference. I haven't determined where the problem is yet,
though.

An inconvenience with Spirit is compile time, especially for larger
grammars. Bison certainly has an edge here ;-). If the Spirit authors
have techniques for reducing compile times, they should mention them in
the documentation. For example, some of my grammars have very large rule
definitions. Is it effective to break rules up into component rules?

Also, a documentation section for common mistakes would be useful. Often
the messages coming out of the compiler are difficult to interpret.

The grammar class template works well enough to separate rules from
specific grammars, however the grammar documentation should make it
more clear why a grammar is useful. The part the begins ``Decoupling
the scanner type...'' contains motivating information which should
be in the very first paragraph.

I've had a breif perusal through the code, and I generally like what I
see, although I'd need more time to look through it more carefully
before making any meaningful conclusions.

Why does the action class template have a default constructor?

I've now seen some of the discussion about the group parser development,
and this seems interesting. I'll have to look though the archives and
learn more about it.

Thanks again for a very useful library.

Dan

-- 
Dan Gohman
dgohman_at_[hidden]