From: dan marsden (danmarsden_at_[hidden])
Date: 2006-05-07 05:20:19
>> 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.
There has been quite a bit of feedback that better quickstart / motivation
material is required. We expect to improve this for the final version of the
documentation.
>
>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?
Yes, seq1 == seq2, seq1 < seq2 etc. all work as you would expect.
>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?
I believe that it is possible Fusion may supercede Boost Tuple. If that is
the case, we will probably make Boost Tuple a conforming Fusion sequence
in order to ease the transition to using the new library.
>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.
Thanks for the detailed documentation feedback. I've incorporated most of
your suggested changes into the latest version of the documentation.
Cheers
Dan