Re: [Boost-users] Spirit Porting

Subject: Re: [Boost-users] Spirit Porting
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-10-28 13:15:45

Bryce Lelbach wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> This is possibly better suited for the Spirit mailing list; however,
> I would like to get as broad an audience as possible here.
>
> Recently, I ported the Boost.Serialization XML grammar from Spirit
> Classic to Spirit Qi. It was a pretty straightforward port, but I did
> expect an increase in the compile-time complexity of building the
> grammar. My reasons for this line of thinking were as follows:
>
>  * Spirit 2.x is fully attributed, while Spirit 1.x is not. This
>    increases both the amount of data that we're dealing with (every
>    parser/generator component must have an attribute), as well as
>    adding additional compile-time checks and transformations which
>  much be applied to that data. * To make Spirit fully attributed,
>    Spirit 2.x uses frameworks that Spirit Classic did not use;
>    Boost.Proto and Boost.Fusion (Fusion was created for Spirit 2.x, I
> believe), as well as a newer version of Boost.Phoenix.
>
> To my knowledge, this new XML grammar is the first Boost component to
> use Spirit
> 2.x (Wave uses Spirit Classic). I believe this means this is the
> first time that software using Spirit 2.x has been placed under the
> scrutiny of Boost testing. Certainly, Spirit 2.x and the underlying
> libraries it uses undergo rigorous testing, but in my mind, testing a
> library and testing software that uses said library are two very
> different processes.
>
> My question stems partially from the thoughts of Serialization's
> maintainer, Robery Ramey:
>
>  "Basically, my view is that we cannot ship something that doesn't
>   work at least as well as the previous version."
>
> My question for you:
>
>  Can software that uses Spirit Classic be ported to Spirit 2.x and
>  retain the same level of compiler/platform compatibility without
>  significant refactoring of the fundamental structure of the Spirit
> components of the software?
>
> Please do note that I believe that there is room in the Serialization
> XML grammar for refactoring, and I certainly don't mean to imply that
> the authors of Spirit, Proto, Fusion or Phoenix are at fault here in
> any way.

I have encouraged and supported Bryce's undertaking on the assumption
that the usage of the latest spirit would improve the xml_iarchive in every
way including performance, maintainability and portability.  This assumption
was inspired and supported by the warnings that spirit classic was 
"deprecated" which
seemed to suggest that it would be in our interest to convert to the latest
spirit.  The xml grammar used in the serialization library is very simple -
what could go wrong?  Well, It is starting to look like this assumption was 
wrong
and I'm very disappointed. I feel the developer's of spirit have let Bryce 
down.
I'm hoping the spirit developers can step up and follow through to
realize the expections developed for this package.

I'm hopeful that a couple of tweaks can reslove the issue - as I said the
xml_archive grammar is a very simple one.  Some of the issues seem simple
as well - compile time with intel compilers, some hiccup deep in mpl
which hangs up the IBM C++ compiler.  And I'm more than hopeful
that the spirit developer's can place a high priority on doing whatever
is necessary to fix this.  The serialization library is one of the highest
profile users of spirit and an easy example and test case.  Once, you
put it out there, it's your responsability to see that it meets the 
expections
you've created for it.

I was very surprised (and disappointed) to find that Wave - a very 
convincing example
of the capabilities of spirit does not use the latest spirit.  Had I known 
that,
I wouldn't have encouraged Bryce with his efforts.

As I said, I'm hopeful that this is not too hard to fix - the spirit library 
tests
are mostly OK (except for the IBM compiler which has to be resolved).  Maybe
you could start by adding a test which builds a grammar similar to the 
xml_archive
grammar.

Robert Ramey