Re: [boost] [review] Fusion review begins

From: Darren Cook (darren_at_[hidden])
Date: 2006-05-05 22:39:49

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

Abstain: this library is too big for the time I have, so I'll just post
some documentation comments.

> - What is your evaluation of the documentation?

The Quick Start is going nicely, but then stops suddenly with a "Tip of
the Iceberg" excuse. The remainder of the documentation is reference
documentation (i.e. the examples in all subsequent sections seem to be
demonstrations of syntax rather than realistic usage examples).

In particular a real-world example for lazy evaluation and some
algorithms other than for_each, showing the traditional C++ code and the
fusion way, to make it clear what advantage it brings.

I'd like to see a page describing the inefficiencies: increased run-time
(or none?) and increased compile-time. Are they basically the same as
boost::tuple?
  http://www.boost.org/libs/tuple/doc/tuple_users_guide.html#performance

(Pedantic documentation comments moved to bottom of this mail)

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

I think the programmer-time-saving for writing load/save/output
functions of classes that are a bunch of variables is useful, and also
helps accuracy. BTW, can it also do operator== as a one-liner?

On the downside the learning curve (not just this library but it assumes
familiarity with Tuples and MPL) would probably stop me using it in any
project where other programmers may have to maintain my code. At least
until I see "Boost Fusion Made Easy" in the bookshops :-).

Does this library supersede Boost Tuples, allowing the latter to be
deprecated if Fusion is accepted into boost? If not, what are the
remaining advantages of boost::tuples?

Darren

Pedantic Documentation Comments:

* The first example in QuickStart should show the using namespace line.
Or footnote 2 should be promoted from being a footnote to become the 2nd
paragraph of this page.

* The first paragraph of the introduction has basically the same first
and last sentence. I think the last sentence should be dropped, and the
first modified slightly to mention tuples.

* In same paragraph, "A list<X> can only hold X instances" sounds
ambiguous: does X mean a number of a type.

So, here is my suggestion for that first paragraph (with a few minor
syntax changes as well):

An advantage of languages such as Python and Lisp/ Scheme, ML and
Haskell, etc., over C++ is the ability to have heterogeneous containers
(also known as tuple types) that can hold arbitrary element types. In
C++ all the standard library containers can only hold a specific type. A
vector<int> can only hold ints, a list<X> can only hold instances of X,
and so on.