From: Larry Evans (cppljevans_at_[hidden])
Date: 2007-04-18 12:59:23
On 04/17/2007 09:24 PM, Maurizio Vitale wrote:
>> (and maybe 0 arguments as
>>Ick, no. It's not obvious what it should mean.
> A way to define it would be similar to what scheme/lisp do for
> operators applied to no arguments: they return the identity
> for the operation.
> For logical and and or, the identities would be #t and #f.
> For grammars, and_ would be something that always matches
> and or_ would be something that never matches,
> Maybe not particularly useful here, because probably nobody
> recurses on grammars this way, but very useful to have
> in scheme and lisp.
> But I think having the same behaviour as mpl::and_ and mpl::or_
> is very important, so if one is changed the other probably should
> as well. The nice thing about this change is that it shouldn't
> make any code that was valid invalid (unless there's a way
> to have SFINAE effects visible).
I've just encounted a need for something like this. For example,
if you have a list of types for which you want to apply the or_ to,
however, that list must by calculated, then the only way to apply
or to it is with a fold operation. Since mpl::fold takes
an argument represening the initial state, this would naturally
be proto::or_<> in case you want to proto::or_ together a list
of types. In my particular use case, I've got 3 enumerations:
which correspond to the terminals, non-terminals, and action
symbols in a grammar. Naturally, these would be used to define the
proto::terminals in some proto representation of the grammar and
I'd use mpl::fold and proto::or_ something like:
where inp is just something derived from say:
Anyhow, I hope you get the idea. I'm still working on it,
but this is what prompted me tho agree with Maurizio's
suggestion that it'd be good to allow or_<>.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk