Re: [boost] Review: The Spirit Parser Framework

From: Joel de Guzman (djowel_at_[hidden])
Date: 2002-10-20 18:23:06

----- Original Message ----- 
From: "Peter Simons" <simons_at_[hidden]>

> The Spirit Parser Framework should be ACCEPTED into Boost for the
> following reasons:

First of all, thanks, Peter. 

[snip]

> Admittedly, the documentation for Spirit could (and should) be more
> extensive -- I remember well that I had some interesting experiences
> when I started using it. But the scope of material that had to be
> covered in the documentation in order to call it "complete" is
> immense. Without a sound understanding of templates, expression
> templates, iterators, and -- obviously -- parser theory, you cannot
> expect to use the library to its full potential. But you cannot expect
> a free-software author to cover all these topics in the user's manual
> either.

Understood. The original Spirit v1.0 post was a paltry 7 header file
and a single html file documentation. Along with the initial boost
announcement came tons of wish-lists which I attempted to address
soon afterwards. Thanks to the help of many others (listed in the
acknowledgement) and especially Dan and Hartmut, development
over the past year has been a rocket ride, so to speak. Now,
there are 8 modules and more than a hundred A4 pages of 
documentation. Yet, many parts are still crying for more documentation 
and a reference material is really needed. As always, the coding outpaces 
the documentation. ... Not to mention that I am not a native english 
speaker :-)

Sooo :-).. I take this opportunity to call for help... I'd certainly be
very happy if someone will come out and help with the documentation 
and especially the reference.

> 2. Portability
> 
> Even though Spirit is built on very sophisticated mechanisms of the
> ISO C++ language, it is highly portable. I have been able to compile
> Spirit-based parsers without significant problems on any of the
> following operating systems:
> 
>     Linux
>     FreeBSD
>     OpenBSD
>     MacOS X
>     Windows
> 
> Furthermore, I was able to compile Spirit with any of the following
> compilers:
> 
>     GNU g++ 2.95, 3.0, 3.1, 3.1
>     Intel C++ 6.0
>     Comeau C++ 4.3.0.1

+ Borland 5.5.1
+  intel 5.0
+  msvc 6/7
+  Visual Age C++ 5.02
+  metrowerks 7.2

[snip]
> 
> 4. Performance
> 
> Spirit parsers are based on expression templates, what allows for some
> serious code optimization by the compiler. The drawback is that
> compile times may be testing your patience, but the idle time during
> compilation is invested well, because the resulting parsers are
> _fast_. It might theoretically be possible to write faster parsers by
> hand, but I don't see any real-life applications where Spirit's
> performance should be insufficient.

I must admit, I'm not quite happy with the compile speed on EDG
based compilers. I must consult with the gurus (Aleksey, help! :-)
to make things smoother with Comeau and others. I remember 
a case where Comeau took hours and gave up with an infinite
recursion. I certainly hope EDG will address this "crawling compiler"
issue which I think is rather ironic: EDG is the best so far in ANSI
c++ conformance yet modern C++ makes it crawl.

> 8. Miscellaneous
> 
> Other reviewers have commented that Spirit would be intertwined with
> the Phoenix library that comes with it. It is true that Phoenix is
> very useful when working with Spirit, and thus it is used throughout
> most of the examples and test programs. But Spirit is completely
> independent of Phoenix and most of the things one does with Phonix can
> be accomplished with Boost.Lambda, Boost.Bind, or any other framework
> as well. All Phoenix-related parts reside in their own namespace and
> in their own directory, so Phoenix and Spirit are really not
> intertwined at all.

I think the culprit is the single header "spirit.hpp" which includes
everything and indirectly includes phoenix. There are a couple of
module header files as well. It is highly advisable to include the
module header files rather than the one-stop-shop-spirit.hpp.

Regards,
--Joel