Re: Fusion-ifying proto parse trees

Eric Niebler wrote:
> Joel de Guzman wrote:
> > Eric Niebler wrote:
> > > Joel de Guzman wrote:
> > > > Eric Niebler wrote:
> > > > >
> > > Expression template trees, by their very nature, are going to be 
> > > linear almost all the time. People write a>>b>>c>>d, not 
> > > (a>>b)>>(c>>d). And the precedence of >> makes it branch in the wrong 
> > > way, so we get the worst-case behavior almost all the time. And I 
> > > can't really think of anything better. :-(
> >
> > That's an inherent limitation of proto compared to hand coded ET.
> > In most cases, in many DSELs, you don't care about grouping of
> > same operators.
>
> Most cases? I disagree. Imagine using proto to build Blitz++ or MTL or 
> the Physical Quantities library or .... Math is a pretty important 
> domain where grouping most certainly does matter. Grouping matters in 
> I/O, too. For example:
>
>     std::cout << ("hello" << "world"); // oops!
>
> Don't let the unique properties of the Spirit DSEL bias you. If we are 
> to have a reusable expression template library, it must be general.

Grouping is important in Spirit too! But my point is that I have
control over where it is important and where it is not. That's the
message I was trying to convey.  I am definitely *not* mislead by
the Spirit DSEL. This is true in *most* languages. There are certainly
operators that do not care about grouping. The issue here is *control*
over those.

> I want you to use proto, and I want to make it easy for you to do so. 
> I'm willing to make changes, so long as they don't make proto a less 
> general tool. I guess I still don't understand your requirements, so 
> let's back up. Please tell me again why you want sequences flattened. It 
> would be helpful if you could also tell me why the code I wrote to make 
> proto trees Fusion sequences is insufficient. I'm sure we can figure 
> something out.

The issue of flattening is based on extensive deliberations on
and off list that will take lots of effort for me to explain in
one post. The discussions go back years. And... no, I didn't
say that your code is insufficient. I think it's pretty cool!

What I am simply saying is that this elaborate dance wouldn't
have been necessary if there was a way to guide or control the
proto-ET phase. It would have been nicer if I can specify my
own hetero-containers to use. In a manner of speaking, proto
is hardwired to use its own specific container. IMO, it should
not need explaining why hardwiring a container is not good in
a library that's supposed to be used generically.

One plausible way is to allow the client to declare/define the
overloads (through macros) in its own namespace with domain tags.
Then, the user can supply some domain specific customization
points for creating the data structures.

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