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
>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
>(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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk