Re: segmented fusion - a-ha!

Joel de Guzman wrote:
> Eric Niebler wrote:
> > I just had an a-ha! moment. Segmentation in Fusion is *so* much 
> > simpler than I was making it. Fusion doesn't need segmented iterators, 
> > it needs segmented sequences! Fusion's algorithms don't take iterators 
> > like the std algorithms do -- they take sequences. I was trying to 
> > shoe-horn Matt Austern's formulation into Fusion, but that's the wrong 
> > approach.
> >
> > Consider the joint_view. It should advertise itself as a segmented 
> > view. Then, the only thing it needs to provide is a way to step 
> > through the internal segments -- which are Fusion sequences that may 
> > or may not be segmented. What you get, essentially, is:
>
> Yeah! This is "make it as simple as possible" thing that I was
> looking for. Essentially, segmented sequences are sequences with
> child sequences (segments). I see:
>
>     traits::is_segmented<Seq>::type // --> mpl::true_/false_
>
> Then for segmented sequences:
>
>     segments(seq) // --> a sequence of sequences
>     result_of::segments<Seq>::type // --> a sequence of sequences type
>
> Now, a joint_view can hold and return a vector2<Sequence1, Sequence2>&
> when its intrinsic "segments" is called (via tag-dispatch).


Even better. :-) And proto::binary_op can hold vector2<Left &, Right &>. 
Oh, this is almost too easy.


> Now, if for_each was an object (ala Fusion1), then segmented for_each
> will simply be:
>
>     for_each(segments(seq), for_each);


Well, almost. You'd need to bind the unary function "f", somehow, like:

    for_each(segments(seq), bind(for_each, _1, f))

or something. But yeah, I get it. And something like fold that returns 
state will be a little trickier, but doable.

Another interesting case is a transform_view on a segmented sequence. 
When you call segments() on such a transform view, you'll get back a 
sequence of transformed sequences.

result_of::segments<TransformView>::type

becomes

transform_view<
    result_of::segments<TransformView::sequence_type>::type
  , apply_transform<TransformView::transform_type>
>

where apply_transform<> looks like:

template<typename F> struct apply_transform
{
    template<typename Sequence> struct result
    {
        typedef transform_view<Sequence &, F> type;
    };

    apply_transform(F const &f)
      : f_(f) {}

    template<typename Sequence>
    transform_view<Sequence &, F>
    operator()(Sequence &seq) const
    {
        return transform_view<Sequence &, F>(seq, f_);
    }
private:
    F const &f_;
};


And is_segmented<TransformView> is simply 
is_segmented<TransformView::sequence_type>. Piece of cake.



> (Strike 1 for object algorithms, Dave?)


If you can bind() arguments to fusion algorithm objects, then yes, 
algorithm objects would make this a little cleaner IMO.



> Effectively, each segment is unrolled for us by the mechanism
> that already exists in fusion!
>
> I think this is cool! This is more elegant than I expected it to be.
> I like it! No, I love it!


Cool! :-)


--
Eric Niebler
Boost Consulting
www.boost-consulting.com


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642