Re: Fusion-ifying proto parse trees

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?


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


Ah, now we're getting to the crux of the matter. :-) Recall an earlier 
message, where you said:

"Awesome! I can't even start to grok the possibilities this allows.
Predictive parsing? LALR? Packrat? Re2C-like lexers? All those can
be a set of *algorithms* working on the proto data-structure.
Combine them at will!"

So I write a set of algorithms that implements a backtracking NFA on top 
of proto (xpressive), someone else writes the LALR algorithms, and 
someone else the predictive parser, etc. And they all work together 
because they all interpret the same proto data structure.

Now, imagine what happens when Spirit changes its data structure. 
Instead of seq<a,seq<b,seq<c,d>>>, Spirit uses spirit_seq<a,b,c,d>. But 
now all the other sets of algorithms that target the standard proto form 
don't work any more with Spirit. They don't "combine at will."

Rather than reducing genericity, proto's standard form actually 
increases genericity because it is an accepted interface that everybody 
can program to.


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


If you go this route, you forfeit unification with Karma, xpressive, and 
a host of other yet-to-be-developed parsing strategies. Instead, let's 
make it trivial and efficient to get flattened views of the proto tree. 
With the new proto/Fusion integration, we have a way forward. And once 
Fusion supports segmented iteration, the whole issue becomes moot. That 
is where we should be directing our energies, not in the Balkanization 
of the proto data structures.


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