Re: Fusion-ifying proto parse trees

Eric Niebler wrote:
> Joel de Guzman wrote:
> > Eric Niebler wrote:
> > > What do you think? Zero-copy expression template construction and 
> > > segmented iteration over the tree -- I think there's potential there.
> >
> > Or, simply use the raw view returned from push_back without doing
> > a fusion::as_list call. That also amounts to zero-copy expression
> > template construction.
>
>
> Yes, sure but then the view returned by push_back will be, essentially, 
> a proto parse tree. :-) And you'll want Fusion algorithms to work 
> efficiently with them, so they should use a segmented iteration scheme. 
> In other words, a Fusion join_view is a text-book example of a segmented 
> data structure. If we add segmented algorithms to Fusion, they'll work 
> better with your lazy views.

Not quite. I still have information about the types of nodes that
are collapsable, so, the resulting view will be essentially flat.
I won't try to convince you, now, other than to say that I've
thought about this scheme already and I *can* prove that the
resulting view is trivially and *externally* iteratable.

> > Pardon my stubbornness. It's just that I always strive to arrive
> > at the simplest solution. For Spirit-2, I'd like to adhere to the
> > mantra that "less is more". Then here we are again adding complexity
> > to tackle what I view as a simple need. I understand that you also wish
> > to make proto "as simple as possible", but what we are doing seems
> > more like moving the complexity somewhere else, and in the process,
> > ultimately adding more complexity to address the need.
>
>
> IMO, Fusion needs this extra complexity. Efficient evaluation of lazy 
> sequences should be Fusion's bread and butter. Did you see how much 
> faster segmented proto was over non-segmented proto? 

Yes, that is indeed very enticing!

> Today's join_views 
> == non-segmented proto == the slow badness. Segmented join_views == mmm, 
> tasty goodness. :-)

No! join_views != non-segmented proto. A joint-view is trivially
iteratable. Same nodes are collapsed to begin with. It's the
grouping of associative operators that makes the difference.
You don't do that in proto and that's the source of my problem
with it.

> I'm also not sure how much complexity there really is. My impression is 
> that making a non-segmented algorithm into a segmented one is a fairly 
> mechanical translation. We may even get by with some Boost.PP magic to 
> do it for us. I haven't tried making a segmented view, but I'm guessing 
> that's fairly mechanical, as well. It's certainly worth looking into 
> IMO, but I'm not trying to deceive you -- this would be a sea-change for 
> Fusion.

For the record, I agree that it would be good fusion to have
the segmented algos. It's just that I am not yet convinced that
Spirit-2 needs to use them. There must be a simpler solution and
that's what I am aiming for.

Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



-------------------------------------------------------
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