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

From: Maurizio Vitale (maurizio.vitale_at_[hidden])
Date: 2007-05-20 17:17:48

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