Re: [boost] Interest for a perl6-like-junctions-class?

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-09 08:37:48

From: Florian Stegner <FlSt_at_[hidden]>
> Rob Stewart wrote:
> >From: FlSt_at_[hidden]
> >
> >My suggestion for each_of was to handle the situation in which
> >each could match independently, whereas with all_of, each must
> >match the same other value.  IOW, given ranges L and R,
> >each_of(L) == any_of(R) means that each value in L may match any
> >value in R, whereas all_of(L) == any_of(R) means each value in L
> >must match any single value in R.  Thus, if L[n] == R[m] for any
> >n in L and m in R, each_of(L) == any_of(R) is true.  However, for
> >all_of(L) == any_of(R), all values of L must equal R[m] for any m
> >in R.
> >
> Now I understand it. If you compare our implementations, this is exactly 
> what not_all_of in my implementation does.

Does that mean that your not_all_of presently means all, but each
taken individually, like my each_of, and that you will change it
to mean any number less than all?  Or have I misunderstood what
you were saying?

> >>>"all_except_one" is quite common situation
> >>>which may be considered too.
> >>>
> >>This is also the same like not_all_of
> >>
> >No.  "all_except_one," or maybe "all_but_one," means exactly
> >N - 1 matches, where N is the length of the range.
> >
> Yes your are right. It is the same like one_of where the result of the 
> predicate is negated. I wouldn't add too much xxx_of operators, because 
> the most expressions of them can be formulated with others.
> one_of( a ) > x means the same as all_except_one( a ) <= x

We can get to the point of adding too many *_of operations, but
we do need to cover the common ones.  Certainly all_but_one is
the same as one_of after negating the predicate, but it may prove
to be sufficiently common that users will want it.  It's a
balancing act, but if there's enough interest, it is better that
we define the operation once in the library.

Perhaps the right initial approach is to provide those needed to
build everything one might need, plus a few very common
simplifying ones, and perhaps document the others that one could
define.

We'll also want to document how to create new ones.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;