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 <j...@boost-consulting.com> Sender: proto-boun...@lists.boost.org Date: Sat, 23 Oct 2010 09:29:27 To: <proto@lists.boost.org> Reply-To: "Discussions about Boost.Proto and DSEL design" <proto@lists.boost.org> 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto