Re: Fusion-ifying proto parse trees

Joel de Guzman wrote:
> Eric Niebler wrote:
> > Joel de Guzman wrote:
> > > 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.
> >
> > It's crucial that I understand the context. Can you point me to the 
> > discussions?
>
> Oh jeez, that will require a bit of searching. I intend to do that
> anyway when I rewrite the design strategies pages, but I'll have to
> defer that work for later.
>
> Anyway, one definite rationale is ease of transformation and
> attribute processing. Given a>>b>>c>>d, the attribute is
> tuple<RA,RB,RC,RD> where RA...RD are the attributes of a...d
> that you can obtain through traits::attribute_of<P>::type.
> It's definitely more convenient to process seq(a,b,c,d) than,
> say, seq(seq(seq(a,b),c),d) and all its permutations (e.g.
> seq(seq(a,b),seq(c,d)). It is a must for semantic handling too.
> Imagine semantic actions receiving different permutations of
> tuple A..D in various grouped forms.


But you'll never have to worry about all the permutations, because you 
will have a view that makes it look flat.

tuple<RA,RB,RC,RD> attrs =
  generate(transform_view((a>>b)>>(c>>d), attribute_of());

The grouping won't matter -- you'll get the same tuple each time. 
Likewise with semantic actions -- you'll never see any permutations.

But you already know this. I'm still very confused -- what is the problem?

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