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

Subject: Re: [proto] Visitor Design Pattern
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2010-10-23 06:57:30

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.
Possible workarounds i can think of:

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

or something like this in the actions:

struct actions::when<some_rule::proto_grammar> : do_it {};

I will get to adapting the mini phoenix today ...

> \e
> 
> Sent via tiny mobile device
> 
> -----Original Message-----
> From: Joel de Guzman <joel_at_[hidden]>
> Sender: proto-bounces_at_[hidden]
> Date: Sat, 23 Oct 2010 09:29:27
> To: <proto_at_[hidden]>
> Reply-To: "Discussions about Boost.Proto and DSEL design"
> 	<proto_at_[hidden]>
> Subject: Re: [proto] Visitor Design Pattern
> 
> On 10/23/2010 5:36 AM, Eric Niebler wrote:
> > On 10/22/2010 10:45 AM, Eric Niebler wrote:
> >> On 10/22/2010 10:01 AM, Thomas Heller wrote:
> >>> I think this is the simplification of client proto code we searched
> >>> for. It probably needs some minor polishment though.
> >> 
> >> <snip>
> >> 
> >> Hi Thomas, this looks promising. I'm digging into this now.
> > 
> > This is so wonderful, I can't /not/ put this in Proto. I just made a
> > small change to proto::matches to VASTLY simplify the implementation
> > (sync up). I also made a few changes:
> > 
> > - The action CRTP base is no more. You can't legally specialize a
> > member template in a derived class anyway.
> > 
> > - Proto::or_, proto::switch_ and proto::if_ are the only branching
> > grammar constructs and need special handling to find the sub-rule that
> > matched. All the nasty logic for that is now mixed in with the
> > implementation of proto::matches (where the information was already
> > available but not exposed).
> > 
> > - You have the option (but not the obligation) to select a rule's
> > default transform when defining the primary "when" template in your
> > actions class. (You can also defer to another action class's "when"
> > template for inheriting actions, but Thomas' code already had that
> > capability.)
> > 
> > - I changed the name from "_traverse" to "algorithm" to reflect its
> > role as a generic way to build algorithms by binding actions to
> > control flow as specified by grammar rules. I also want to avoid any
> > possible future conflict with Dan Marsden's Traverse library, which I
> > hope to reuse in Proto. That said ... the name "algorithm" sucks and
> > I'd like to do better. Naming is hard.
> > 
> > - The algorithm class is also a grammar (in addition to a transform)
> > that matches its Grammar template parameter. When you pass an
> > expression that does not match the grammar, it is now a precondition
> > violation. That is consistent with the rest of Proto.
> > 
> > That's it. It's simple, elegant, powerful, and orthogonal to and fits
> > in well with the rest of Proto. I think we have a winner. Good job!
> 
> Sweet! It's so deliciously good!
> 
> I too don't quite like "algorithm". How about just simply "action"?
> 
>    std::cout << action<char_terminal, my_actions>()(a)  << "\n"; //
> printing char
> 
> or maybe "on":
> 
>    std::cout << on<char_terminal, my_actions>()(a)  << "\n"; // printing
> char
> 
> Regards,