Proto for Boost mailing list page: Re: [proto] Visitor Design Pattern

Subject: Re: [proto] Visitor Design Pattern
From: Eric Niebler (eric_at_[hidden])
Date: 2010-10-23 13:12:06

On 10/23/2010 3:57 AM, Thomas Heller wrote:
> On Saturday 23 October 2010 07:13:56 eric_at_[hidden] wrote:
>> Actually, I may have been hasty. I've had a hard time porting my
>> mini-Phoenix to proto::algorithm. Thomas, can you, either with your
>> version or mine? Proto::switch_ doesn't play nicely with it.
> 
> Yes you are right ... there is a pitfall to that ...
> Having the cases look like:
> 
> struct cases::case_<Tag> : some_rule {};
> 
> There is no way the grammar can pick up some_rule to index the action.

Another way of phrasing it is: we have given "some_rule" a name so we
can index on it, but we haven't given Proto access to the rule name in
all cases.

This is half the problem. The other half is getting Proto to know when
it has found a named rule, or when it should keep looking. For instance:

struct cases::case_<Tag> :
  proto::or_<
      some_rule
    , some_other_rule
  >
{};

Clearly, we don't want to index on cases::case_<Tag>. We want Proto to
look inside the or_ and pick either some_rule or some_other_rule, and
use those to look up the action.

Both of these problems can be solved if we explicitly bind a name to a
rule in a way that Proto can find it. We can do this with a "named_rule"
template. Now, instead of this:

  struct some_rule
    : proto::or_< ... >
  {};

we have this:

  struct some_rule
    : proto::named_rule<
          some_rule
        , proto::or_< ... >
      >
  {};

This eliminates the pitfalls you mentioned in your earlier mail and
solves the look-up ambiguities.

I've tweaked both the traversal example you sent around as well as my
over toy Phoenix. Tell me what you guys think.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com