Re: [boost] proto::or_ arity

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
>>
>>>well).
>>
>>
>>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:

   enum sym_inp{...};
   enum sym_out{...};
   enum sym_act{...}

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:

   struct
grm_symbol
: proto::or_
   < inp<inp_0>::type
   , inp<inp_1>::type
   , out<out_0>::type
   , out<out_1>::type
   , out<out_2>::type
   >
{};

where inp is just something derived from say:

   proto::terminal<some_wrap<inp_0> >

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