Boost logo

Boost :

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 :

But you certainly have more usages in mind than I do to decide whether proto::any
and proto::all are good choices.



[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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at