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

Subject: Re: [proto] Visitor Design Pattern
From: eric_at_[hidden]
Date: 2010-10-23 01:13:56

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. 

\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,
-- 
Joel de Guzman
http://www.boostpro.com

http://spirit.sf.net




_______________________________________________
proto mailing list
proto_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/proto