Re: spirit grammar graphs

On 03/30/11 21:53, Gordon Woodhull wrote:
> Hi Larry -
>
> On Mar 30, 2011, at 8:20 PM, Larry Evans wrote:
>>        mout()<<"test:3 subrules with sr0 terminal\n";
>>        spirit_simple::subrule<0> sr0;
>>        spirit_simple::subrule<1> sr1;
>>        spirit_simple::subrule<2> sr2;
>>        spirit_simple::terminal term0;
>>      #ifndef SubruleMapBuildMethodTemplate
>>            typedef
>>          map
>>          < typeof(sr0=sr1>>term0)
>>          , typeof(sr1=sr2)
>>          , typeof(sr2=sr0)
>>>
>>        lhs2rhs_map0
>>        ;
>>
>> where map is the mpl::map; hence, is generated at compile time.
>> The, sr0....sr2, are non-terminals, and term0 is a terminal in the
>> grammar defined by productions:
>>
>>  sr0=sr1>>term0
>>  sr1=sr2
>>  sr2=sr0
>
> Yes!  I was thinking something similar.  I'll take a look and maybe
> put a reference in my paper.  :-D
>
>>
>> Note, there's only 1 binary operator, >>, but it should be no problem
>> to define others similarly.  Also note that the grammar productions do
>> contain a cycle:
>>
>>  sr0->sr1->sr2->sr0
>>
>> Hope the code gives you some ideas :)
>
> Nice proof-of-concept; I think so!  I bet you didn't try to cross
> the runtime barrier so you could have live data in there,

I'm not quite sure what you mean.  In the zip file, there also output
of the run, which shows some sort of traversal of the tree.  I'm not
sure if it does show going through the cycle mentioned above, but I
would expect it would.

> but I think there's a way to do it with proto.

There's a prototype of something similar using proto.  That's in the
same vault directory.  It was used to calculate lookahead sets using
the method shown in the LLewiLL1 zip file in same vault directory.  I
believe that proto file is in the cfg_lookahead.extends.zip.

>
> Seems like at worst you could have the whole grammar as a proto
> expression and produce the whole grammar graph at once.  Another
> possibility is that each statement produces a tree and they are
> glued together afterward.

The way the subrule_simple*.zip did it, IIRC, was that, instead of
using pointers from the rhs of one rule to the lhs of another rule,
each rule had a key, and that key was the key in the map.  Now, again,
IIRC, the key was used to call the lhs parsing routine from the body
of another rule's body by using a templated function where the
template argument was the rule's key; hence, I *think* there was no
virtual function calling required.  However, I'd have to look at the
code again to make sure.  I do remember one of the hardest problems
was avoiding that virtual function call.  I think CRTP was used to
help eliminate it, but I'm not sure.  Again, I'd have to look again at
the code.

>
> Well I better not think too much on a tangent here.
>
>> Good luck.
>
> Obviously I'm not trying to implement this before May, just looking
> for some interesting examples for my talk at this point.

Sounds interesting.

>
> Thanks!
> Gordon
>
You're most welcome.

Larry



------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf