Re: [Boost-users] [Spirit 2] Questions related to generating grammars meta-dynamically

Subject: Re: [Boost-users] [Spirit 2] Questions related to generating grammars meta-dynamically
From: Richard (legalize+jeeves_at_[hidden])
Date: 2010-11-30 13:35:25

[Please do not mail me a copy of your followup]

boost-users_at_[hidden] spake the secret code
<4CF42BF1.5090607_at_[hidden]> thusly:

>> locals<>  are - well - local to the rule they are defined for. Each
>> invocation of that rule creates a new instance of the local variables, very
>> much like local vaiables in functions.
>
>So if I have something like this (a very much contrived example):
>
>struct myGrammar: grammar< .... >
>{
>     rule< .... locals< types > .... > some_rule;
>
>     myGrammar() : base_type( .... ) {
>        some_rule = parser_1[ _a = _1 ] << parser_2( _a );
>     }
>};
>
>then "_a" would indeed refer to "some_rule"'s local variable?

As I understand Spirit/Phoenix: yes.

>Are the 
>grammar's local variables effectively identical to its start rule's 
>local variables? Ditto _val and _rN?

My understanding is that rules have local variables, synthesized
attributes and inherited attributes.

I never thought about how this applies to grammars, but I suspect that
you're right: the grammar exposes the start rule's synthesized
attribute as its attribute and exposes the start rule's inherited
attributes of the start rule as its inherited attributes.

>> http://boost-spirit.com/home/articles/qi-example/nabialek-trick/
>
>This looks very similar to what I'm trying to do, thank you very much! 
>Unfortunately I have next to no experience with Spirit (or Fusion... or 
>Phoenix... :) ) even though I've been using many other Boost libraries 
>for ages, so once I can't resolve something by looking in the docs I 
>don't really know what to google for...

I played a little with Spirit V1 and am now getting back into Spirit
V2.  For what its worth, V2 is much easier to get going than V1 IMO.

My advice is to take things one step at a time.  Don't try to write a
grammar that covers all the complexity of your input.  Start with the
simplest piece of the input and write a parser for that.  Gradually
add more rules to your grammar as you cover more complexity in the
input.

You can either develop the whole parsing bit first and then work on
the semantic actions associated with each rule, or you can ping-pong
back and forth between parsing and actions.  I don't know which is
better yet.  I've been doing a little bit of both.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>