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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-07 15:09:44

> From: "Pavel Vozenilek" <pavel_vozenilek_at_[hidden]>
> Date: Tue, 2 Aug 2005 16:43:56 +0200
> Reply-To: boost_at_[hidden]
> Sender: boost-bounces_at_[hidden]
> 
> ________________________________________________________
> 6. Would it be possible to have other qualifiers,
>    e.g.: "more_than_half_of"
> 
> 
>  if (more_than_half_of(a) >= any_of(b)) ...
> 
> 
> or more complex versions like:
> 
>   more_than(10).items_of(a) >= ...
>   more_than(30.1).percents_of(a) == ...
> 
>  less_than(2).items_of(a) >= ...
>  less_than(95).percents_of(a) == ...
> 
>   between(1, 5).items_of(a) >= ...
>   between(10.5, 20.0).percents_of(a) == ....
> 
>   exactly(10).items_of(a) >= ....
> 
> ________________________________________________________
> 7. Will it be possible to use other predicates than
>    >, <=, etc  in following form:
> 
> 
>   if ( is_true_that(all_of(a), a_binary_functor, one_of(b)) ) ...
> 
> where the functor could be lambda:
> 
>   if (is_true_that(all_of(a), _1 >= _2, one_of(b)) ....
> 
> It feels more natural than the asymetric "do_comparison".
> 
> ________________________________________________________
> 8. If the "is_true_that" will be implemented than
>    a filter "where" could be considered, like:
> 
> 
>    if ( is_true_that(all_of(a), _1 >= _2, 
> one_of(b) ).where(_1->does_fulfill_condition()) ) ...
> 
> and the "where" fould have unary predicate as parameter,
> this predicate would filter out undesirable items from
> both ranges.

I've been thinking about these ideas further.  They are mostly
set manipulations and probably should be part of another
library rather than the junctions/multivalues idea we're working
at this point.  Manipulating ranges and filtering them is a wide
open field that should be addressed by its own library.  However,
there may be room to implement some of the ideas.

The junctions/multivalues idea is simply to compare a range with
a scalar, or two ranges, and produce a Boolean.

We presently support these operations:

   all
   any
   each
   n_m
   n
   none
   not_all
   one

Do we need more?  Remember that these names encapsulate
operations, not filters:

  |operation|behavior|
  |all      | if any fails, the expression is false
  |any      | if any succeeds, the expression is true
  |each     | if each succeeds independently, the expression
  |         | is true
  |n_m      | if at least n and no more than m succeed, the
  |         | expression is true
  |n        | if exactly n succeed, the expression is true
  |none     | if any succeeds, the expression is false
  |not_all  | if all succeed, the express is false
  |one      | if exactly one succeeds, the expression is true

"one" is syntactic sugar for "n" which is syntactic sugar for
"n_m."  "not_all" is syntactic sugar for "!any."  ("none" is
really just syntactic sugar for "n," but also has a slightly more
straightforward (and efficient) implementation.)

Pavel's syntax ideas--more_than(x).items_of(a)--are interesting.
"percent_of" seems limiting, but "fraction_of" doesn't read as
well.  I also wonder whether "percent_of" is in the realm of that
other library I keep mentioning.

How do these look?

   at_least(n).of(a)
   between(x, y).of(a)
   exactly(n).of(a)
   less_than(n).of(a)
   more_than(n).of(a)

With those, we'd still keep the following *_of() operations
because they otherwise require the computation of the range's
length to use one of the above:

   all_of(a)
   each_of(a)
   not_all_of(a)

Of course "at_least," "exactly," "less_than," and "more_than" are
syntactic sugar for "between."  By the same token, you could
argue to keep "any_of," "none," and "one" as syntactic sugar for
their alternatives.

What do you think is the complete set of operations?

Should we include "percent_of?"

Should we provide the alternate spellings like "at_least,"
"more_than," and "one?"

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