On May 20, 2007, at 4:26 PM, Eric Niebler wrote:
1) any<> doesn't suggest that alternates are tried in order
neither does or_, at least not to me.
2) Neither suggest short-circuiting
ditto. Unless you mean: given that people will come from C++ they're probably likely to read C++ semantics when presented with C++ names. So yes, I agree or_ and and_ may mean a bit more than any and all to C++ people. I guess the tradeoff is whether introducing new names and documenting their behaviour is more or less problematic than the naming conflict w/ the mpl.
3) You haven't said what proto::if_ and proto::not_ should be.
I didn't indeed. The reason is that I was concerned with tags that can appear in expressions and have a different name in MPL. Then if_ wouldn't be a problem and not_ could stay (I'd say should stay) because has the same meaning as mpl::not_. If you want to change both, a possibility would when (for if_) and unless (for not_). But I'd maintain that the not_ in expressions should stay unchanged.
(3) is the killer. Taken together, and_, or_, not_ and if_ give users an expressive and intuitive framework for reasoning about their grammars. Changing just "and_" and "or_" to "all" and "any" would break the symmetry.
all, any, when, unless seem reasonable to me. But again my point was not a "my names are better than yours" kind of contest, rather finding an acceptable way for giving the same names to things that are the same across proto and mpl.
Footnotes: [1] actually I have a fundamental problem with 'or_' (and 'any') as they both focus on one part of what they do: certainly the pattern matches if any of the component patterns match. What they fail to convey is that the _first_ pattern that matches is used for further processing, like evaluating the result of a transform.
True. Many of the types in proto have 2 and sometimes 3 roles. For instance, proto::plus<> is:
- An expression generator. (proto::plus<A,B>::type is the type of a plus node in an expression tree, where A and B are the types of the children expressions.) - A pattern. (proto::plus<A',B'> matches the expression generated by the above if A' and B' are patterns that match A and B, for instance.) - A transform. (proto::plus<A',B'>::apply< E, S, V >::type will apply a pass-through transform to E, with S state and V visitor.)
If_ and not_ also have default "identity" transforms. Even proto::expr<> can be used as a pattern (it matches itself) and as a transform (the identity transform)!
But I cannot come up with a name that describe these two facets satisfactorily, so I guess documentation will have to supplement the name.
I don't think it's a problem.
And now that I think of it, I have no clue of what a transform with a proto::and_ at the toplevel would do. Time to look at docs/source code I guess.
By default, proto::and_ applies the transform of the last branch that matches, just as proto::or_ applies the transform of the first branch that matches. It's somewhat arbitrary, I admit, but I've found this a useful default.
-- Eric Niebler Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost