Re: [boost] [proto] new version, breaking changes

From: Maurizio Vitale (mav_at_[hidden])
Date: 2007-05-20 13:34:56

Eric Niebler <eric_at_[hidden]> writes:

> Maurizio Vitale wrote:
>> Eric Niebler <eric_at_[hidden]> 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.