RE: Re: Spirit-2 and Subversion

Joel de Guzman wrote:

> > One thing I'm certain I misunderstood was your beautiful 
> insight about 
> > parse just being fold. I was still thinking of defining a slew of 
> > spirit::parse overloads, but now I see that we can use proto's 
> > compilers to *evaluate* the ET tree instead of transforming 
> it. As I 
> > mentioned, proto has a fold_compiler which behaves like 
> > std::accumulate. For xpressive, the "state" is the 
> transformed tree so 
> > far, but for Spirit, the "state" can be a simple bool 
> representing the 
> > success or failure of the parse. This was a very deep insight -- I 
> > didn't understand what you were saying until this morning.
> > 
> > It now occurs to me that proto's fold_compiler should be renamed 
> > reverse_fold_compiler, since it evaluates back-to-front 
> (like building 
> > a linked list by pushing new things to the front). Spirit 
> will want to 
> > evaluate front-to-back so that the parsers in front execute 
> first and 
> > pass their "state" (whether they succeeded or failed) 
> farther down the 
> > tree.
> > 
> > I'm not sure what the advantage of doing it this way is, 
> besides a bit 
> > of code reuse. But it's certainly an interesting thought! It never 
> > occurred to me to use proto that way.
> 
> It all boils down to the re-realization that all you need is 
> the data structure (the ET tree) and algorithms that walk it 
> (e.g. tranform and fold/accumulate). I think that going this 
> path gives us ultimate reuse. I see it this way:
> 
> 1) A proto ET tree is a heterogenuous container not unlike tuple.
>     It can and should be a fusion conforming container.
> 2) Proto can provide various "views" over the data to flatten it
>     in various ways (e.g. pre-order (prefix), post-order (postfix),
>     in-order (infix), and other special custom orders (e.g. node
>     collapsing like the one for sequence which turns recursive
>     binary nodes like a >> b >> c into an n-ary node) ).
> 3) Take advantage of fusion's algorithms to do the actual folds
>     and transforms, etc. For example, in the current code base,
>     sequence parsing is just an application of negated fusion::any
>     or fusion::none algorithm (return true if none of the elements
>     fail). In that sense, all operations from parsing to compiling
>     "phases" can be written down as function (algorithm) composition.

IIUC, proto should emerge to be another tree-like Fusion type. Then the
Spirit/Karma ET transformations will build a Fusion tree instance
representing the ET expression. We could apply the existing Fusion
algo's/views to transform/flatten whatever etc. And the Spirit and Karma
libraries would boil down to a set of overloaded free functions, one
overload for each possible ET tree node type.

The primitives we have today (char_, int_ etc.) are nothing else than tagged
node type instances, i.e. char_ is just a nullary_op<char_tag>, char_('x')
generates a unary_op<Char, char_tag> holding the 'x' as its member etc.
(actually the nullary_op is equivalent to a unary_op<void_, char_tag>).

Yeah, looks really smooth to me, even if it results in a Spirit/Karma
library structure very different from what we've seen today. Almost no
objects anymore, only free functions. Let's hope, that the overload
mechanisms of the current compilers are not as buggy as have been certain
template features.

Regards Hartmut

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