Re: [proto] Thoughts on traversing proto expressions and reusing grammar
On 10/20/2010 11:41 PM, Thomas Heller wrote:
On Thu, Oct 21, 2010 at 7:50 AM, Thomas Heller
thom.hel...@googlemail.com wrote:
On Thursday 21 October 2010 05:11:49 Eric Niebler wrote:
On 10/20/2010 7:49 AM, Thomas Heller wrote:
snip
Here it goes:
namespace detail
{
template
typename Grammar, typename Visitor, typename IsRule = void
struct algorithm_case
: Grammar
{};
Why inherit from Grammar here instead of:
: proto::when
Grammar
, typename Visitor::template visitGrammar
?
Because I wanted to have an escape point. There might be some valid
usecase, that does not want to dispatch to the Visitor/Actions. This is btw
the reason i didn't reuse or_, but introduced the rules template. To
distinguish between: 1) regular proto grammars -- no dispatch 2) the
rules, which do the dispatch.
Ok ... after rereading your mini phoenix you solve that problem with
default_actions.
Very neat as well!
Right. In fact, I don't think it's necessary or desirable to let the
Grammar parameter to algorithm_case be anything that isn't an
instantiation of rules. That is, you have algorithm_case and
algorithm_case_rule. Nuke algorithm_case and rename algorithm_case_rule
to algorithm_case. Also, nuke rule. The variadic rules is all that's
needed. A few orthogonal features are better than lots needless
distracting flexibility.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Thoughts on traversing proto expressions and reusing grammar
On 10/21/10 11:11 AM, Eric Niebler wrote: On 10/20/2010 7:49 AM, Thomas Heller wrote: I worked a little on trying to simplify that whole grammar with rules that have thing a bit. Forgive me, but i changed the name to Visitor. Why? Simply because i think this is what is done here. We visit a specific node which happened to match our rule. Most tree traversal algorithms visit each node, but the term Visitor means something very, very specific: the Gang-of-Four Visitor Design Pattern. It implies an OO hierarchy, a virtual Dispatch member that accepts a visitor, and a 2nd dispatch to an Accept member of the visitor object. It is used to add members to an OO hierarchy post-hoc by putting them in a visitor instead of having to change every type in your hierarchy. If you don't have something like that, then don't call it Visitor. If you do, then we need to reformulate this design to make that pattern more explicit. Otherwise, it will cause no end of confusion. Historical note: I originally called the data parameter of Proto transforms visitors. During the review, there was such a hue and cry (for good reason) that I had to change it. True story. Do you mean that it has to be exactly that to be called a visitor? How exact? Does it have to be an OO hierarchy with a virtual Dispatch member that accepts a visitor? Does the Boost Variant visitation scheme (for example) satisfy these conditions? 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
Re: [proto] Visitor Design Pattern
On 10/21/2010 6:41 PM, Joel de Guzman wrote: I like it when we are talking on a conceptual level :-). I think part of the difficulty is in combining two domains: language/parsing and OOP. nod As much as I do not have any problems with visitation, it's also intersecting with the notion of semantic actions. If we add yet one more set of parlance: schemas and documents (which is not totally unrelated -- schemas are basically just grammars), I'm afraid we'll add more confusion. Thanks, Joel. Yes, let's not mix our metaphors. (But I do think that XML/Schema shares much with Language/Grammar. And a Proto expression is quite a lot like an XML DOM in that is has a tree structure, and the Schema describes the valid trees. But yes, we're talking about DSLs and compiler-construction toolkits, so I can keep the XML/Schema talk to myself. :-) I'd say stick to only one domain's parlance. Since proto is closer to the language/parsing domain, I think we should stick to (semantic)actions, rules, grammars etc. This is my feeling as well. If you want to go meta on parsing, then you might get some inspiration on 2-level grammars (inspired by van Wijngaarden grammars) with the notion of hyper-rules, etc. This document: http://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf gives a better glimpse into 2-level grammars (see Annex A). Although the notation (also known as a van Wijngaarden grammar, or a W-grammar) is more powerful, it is more complicated and, as the authors of Algol 68 recognized, “may be difficult for the uninitiated reader”. I'm not really sure how this relates to the current design, but I think we should be getting closer to this domain and it deserves some notice. You're not the first to bring up vW-grammars in relation to Proto. Someone suggested them to implement EDSL type systems. I spent a good amount of time reading about them, and could get my head around it. My understanding is that they're powerfully descriptive, but that building compilers with vW-grammars is very expensive. I don't really know. I think I'd need to work with a domain expert to make that happen. Any volunteers? :-) -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
