On Saturday 23 October 2010 07:13:56 e...@boostpro.com 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 <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,
_______________________________________________
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
