Re: [boost] [review] Fusion review begins

From: dan marsden (danmarsden_at_[hidden])
Date: 2006-05-06 17:49:20

>Hi,
>
>Not a full review of fusion, but just some (slightly confused...apologies)
>thoughts. I started to look into fusion to try to understand what it is exactly.
>I have an idea what it might be about so I decided to look in the examples
>directory. Is there only one example? I am surprised. is that due to lack of
>time? There also doesnt seem to be much in way of examples in the documentation.

I think there are a couple of points here:
1) Examples: In the docs I think there are quite a few examples, roughly one per
algorithm in the algorithms section, similarly one per iterator function. I've not checked
the whole of the sequences stuff, but that also seems to have a few examples. Was
there a section in particular here where you felt we were lacking in examples? Or were
you looking for larger / different types of example?

As to code examples, yes one example covering the extension stuff is pretty
minimal. The tests should provide a great deal of additional examples, although
we agree more code specifically intended for examples would be better. We did
not add more pre-review as we lacked inspiration for short but interesting examples
that would prove instructive. We've had a few ideas since, and will aim to add at
least a couple more examples to the final release.

2) Motiviation
There has been quite a bit of feedback that we need to express the motivation
for using the library in more detail. Again we've got some ideas in this area, helped
by feedback from other reviewers, so we will produce improvements in
this area for the final documentation.

>Would it be possible to have a simple definition of what a view is, as it doesnt
>seem to be defined anywhere, or is it? How expensive is it to construct a view
>at runtime. Is it likely that the view is easy for the compiler to optimise (IOW
>so that the actual code references the original sequence).

There's a bit of detail in the views section, but I'll have a look at addressing the
points you mention in more detail, as the views are an important concept for the
lib.

>I am kind of interested in this library ( though unsure if it can help exactly
>with my problems),  I have a matrix which is in fact a tuple of tuples and I'm
>wondering if fusion could help me in iterating over it. For example currently I
>am writing out each co_factor function explicitly ( of which there are 16)
>though I presume it would be possible to find the generic algorithm, so writing
>one function:
>
>// cofactor function of 3D homogeneous matrix
>// constrained to cofactor(0,0) using enable_if
>
>template<int R, int C>
>        typename boost::enable_if_c<
>            R == 0 && C ==0,
>            value_type
>        >::type
>        cofactor()const
>        {
>            value_type t
>                = (   this->at<1,1>()
>                        * ( this->at<2,2>() * this->at<3,3>() - this->at<2,3>()
>*  this->at<3,2>())
>                    - this->at<1,2>()
>                        * ( this->at<2,1>() * this->at<3,3>() - this->at<2,3>()
>*  this->at<3,1>())
>                    + this->at<1,3>()
>                        * ( this->at<2,1>() * this->at<3,2>() - this->at<2,2>()
>*  this->at<3,1>())
>                 );
>            return t;
>        }
>
>There probably isnt enough detail here to provide a solution to this particular
>problem, but does it look like the sort of problem that fusion could help with?.
>

IMO this is a good example of the type of code that would benefit from the
features of fusion. You seem to have data of known type and size at compile
time, which is the main prerequisite. If the code above operated on a sequence
of fusion sequences, application of fusion::fold and fusion::transform looks like
the right place to start replacing the iteration boilerplate with library code.

Thanks for the feedback.
Cheers
Dan