[Boost-users] [review] Boost.Fusion

From: João Abecasis (jpabecasis_at_[hidden])
Date: 2006-05-13 22:15:12

Hi!

This is my review of the Fusion library. Sorry for the late review...

I should probably state my bias, I've known Fusion since it was bundled 
with Spirit and have wanted to see it in Boost ever since I started to 
grasp its usefulness (I'll admit it wasn't right away... docs were 
scarce back then ;-) ). I've commented on Fusion occasionally and have 
contributed patches and code.

> Please always explicitly state in your review, whether you think the  
> library should be accepted into Boost.

Yes, I think Fusion should be an official part of Boost.

Fusion has been in development for a couple of years and is a mature 
library. It is unofficially part of Boost, it is available under the 
Spirit tree. Fusion is being used by a growing number of official and 
proposed Boost libraries. It is instrumental in the redesign of Spirit 
and Phoenix (in queue for review?) and also in the fork and 
generalization of Proto (out of Xpressive), as a general-purpose 
Expression Templates library.

There's really no excuse for a library of this caliber to be relegated 
to an implementation detail.

There are a few configuration macros whose default value is hardcoded to 
10. They are,

     FUSION_MAX_UNPACK_ARG_SIZE
     FUSION_MAX_VECTOR_SIZE
     FUSION_MAX_SET_SIZE
     FUSION_MAX_LIST_SIZE
     FUSION_MAX_MAP_SIZE

. I'd like to see a single macro to globally set the default value for 
all the others. Which also reminds me, all macros still need to be 
BOOST_ified.

> - What is your evaluation of the design?

Fusion builds on top of the design of MPL and also of the STL so I don't 
have much to say in this regard. It is also a mature library that has 
been in development for some time. In the past I've noticed minor 
inconsistencies between MPL and Fusion, which I reported back (the lack 
of unpack_args was one of them). I think these two libraries, as much as 
possible, should be kept in sync.

Apart from interface exposed to library users, another important aspect 
is the interface for extension. In Fusion-1, implementing a new iterator 
type required one to specialize not only Fusion intrinsics, but also mpl 
intrinsics. Things have improved since then, but I didn't look into this 
specifically for the review. I'll try to share any comments at another time.

The algorithms also look straightforward to implement and the algorithms 
already in the library are a testament to that.

On the directory structure used for the headers, I like the modular 
approach but sometimes get the feeling that it's too fragmented. Having 
more top-level reflections of individual components would ease my 
concerns. Another aspect is that this structure diverges from what is 
used in MPL. Given the parallel between the two libraries I think an 
effort should be made to keep the structure similar. In fact, this is 
also part of the user interface. Still, in the end, I recognize that 
they're two independent libraries and must each follow its path.

> - What is your evaluation of the implementation?

The implementation is very readable and even simple to grasp, once one 
understands a few fundamental concepts. Although this aspect is not 
required of a Boost library, I think it is great when it can be achieved.

Fusion is coded with the expectation that the library code will be 
optimized into very tight code, which seems to be a reasonable 
assumption with (any?) modern compilers.

I would like to see more compile-time concept checks and "friendlier" 
error messages added to the implementation. Ideally, the user should 
never see errors beyond what s/he directly uses. Unfortunately, however, 
at places this will be at odds with the simplicity and readability of 
the code.

> - What is your evaluation of the documentation?

I think I shouldn't be allowed to comment on this department... Anyway, 
I think the docs still need some work, but I generally like the 
direction. I'll try to offer Joel and Dan specific comments later.

For the record, and while it is no excuse, it should be noted that Joel 
de Guzman is one of the lead developers of QuickBook (the other one 
being Eric Niebler), which makes it harder to write the docs... I mean, 
he can't simply complain about the tools. I'm sure Joel is taking notes 
and, in the end, QuickBook and the rest of us will benefit as well :-)

> - What is your evaluation of the potential usefulness of the library?

I believe Fusion has great potential as a library building block but 
also as a more application-oriented library. On the library building 
block side, I believe it has the potential to become a fundamental/core 
piece of Boost. For application developers, Fusion takes tuples to a new 
level, allowing one to make the most of information that is available at 
compile-time.

> - Did you try to use the library? With what compiler?

Yes. Mostly with gcc (3.4 and over), also with intel-9.0 (IIRC), both 
under linux.

>   Did you have any problems?

No. Joel and Dan have been very helpful and supportive for any doubts 
and issues I have had and given the readability of the code I have been 
known to provide fixes to typos and other minor issues.

> - How much effort did you put into your evaluation? A glance? A
>   quick reading? In-depth study?

I suppose it qualifies as an in-depth study for the code and a quick 
reading for the docs. I've followed Fusion evolution since version 1 and 
have perused the code thoroughly. I implemented unpack_args for fusion-1 
for my own purposes and later ported and contributed it to fusion-2.

As a user of the library, I've privately used Fusion to re-implement and 
extend Spirit's closures, to allow members to selected and aggregated 
for return. Something like,

     closure<int, return_<float>, return_<double> >;

, in the context of Spirit, would make a parser return a Fusion.Sequence 
of <float, double>. If also used Fusion in other pet projects.

> - Are you knowledgeable about the problem domain?

I'm not sure I can categorize Fusion into a single and specific problem 
domain. I think the potential use cases are vast and the domain too 
broad. I can't claim to be knowledgeable in all the possibilities it allows.

I'd like to congratulate the developers of the library on the great 
library and thank them for exploring the concepts and bringing it to us! 
I really expect to see Fusion as an official Boost library, soon ;-)

Best regards,

João