Eric Niebler <eric@boost-consulting.com> writes:
Maurizio Vitale wrote:
Eric Niebler <eric@boost-consulting.com> writes:
I've just noticed you still have {left,right}_shift vs. shift_{left,right} of boost::mpl. You're right. I'll change this, but probably not until after BoostCon.
Found some more: bitwise_{and,or,xor} for boost::mpl bit{and,or,xor}_
And then you have these, although here is a tougher call: logical_{and,or,not} for boost::mpl::{and,or,not}_ The problem here is that proto already has and_, or_ and not_
This is tough. Proto has bitwise_or, logical_or and or_, and they mean different things. For instance, you can make a grammar like:
struct MyGrammar : proto::or_< proto::logical_or<_, _> // match "a || b" , proto::bitwise_or<_, _> // match "a | b" > {};
Logical_or and bitwise_or correspond to operator|| and operator|, respectively. Proto::or_, on the other hand, is used to express alternates in a proto grammar.
If we followed mpl's naming convention here, I would rename bitwise_or to bitor_, logical_or to or_, and or_ to something else. But I don't really like that. For the moment, I'm inclined to leave this as-is. I'm open to suggestions.
I know you've already stated you feel proto::or_ and proto::and_ are the right names. And if it wasn't for trying to solve the naming conflicts with the MPL I wouldn't have any issues with this choice. But I'll try anyhow. What about following Haskell (from the list prelude, not pattern handling) and having proto::or_ become proto::any[1] and proto::and_ become proto::all? This would free the present names for the other changes. I think the follwing doesn't look bad: struct My_Grammar : proto::any< proto::or_<_,_>, proto::bitor_<_,_> > {}; But you certainly have more usages in mind than I do to decide whether proto::any and proto::all are good choices. Regards, Maurizio 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. But I cannot come up with a name that describe these two facets satisfactorily, so I guess documentation will have to supplement the name. 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.