From: João Abecasis (jpabecasis_at_[hidden])
Date: 2006-05-13 22:15:12
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,
. 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
> - 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
> - 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
> - 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
> 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 ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk