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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-02 20:23:44

From: "Pavel Vozenilek" <pavel_vozenilek_at_[hidden]>
> "Rob Stewart" wrote:
> 
> >> Comparison between two "mores" would be
> >> disabled.
> >
> > Why?
> >
> Because
>   if (more_than_half_of(a) >= more_than_half_of(b)) ...
> doesn't make sense.

It does to me.

Suppose a is the set of female students and b the male students.
Further suppose that >= compares grades.  Then the expression
asks whether more than half of the girls got grades at least as
high as more than half of the boys.

>  ________________________________________________________
> >> 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".
> >
> > I agree with the asymmetry of do_comparison(), but is it
> > necessary to provide the additional predicate support?
> >
> Yes. Forcing user to define == etc operators doesn't make
> good design and there could be many, many possible
> predicates for single class.

If you allow that, then symmetry cannot be guarranteed.  There's
already a question as to whether the operators must be
symmetrical.  I've posited that asymmetry will lead to confusion,
but many comparisons sound asymmetrical.  Consider these two
expressions:

   none_of(a) == any_of(b) // 1

   any_of(a) == none_of(b) // 2

1. Sounds like it should be true if none of the values in a equal
   any value in b.

2. Sounds like it should be true if any of the values in a equals
   none of the values in b.

Florian's notion of these operators, derived from Perl, is that
they are not symmetrical.  To make expressions like 1 and 2
symmetrical, I've taken to swapping arguments depending upon the
combination of types, which means I'm forcing the symmetry.
Maybe I'm just off the mark and they should be allowed to be
asymmetrical.

> > Reasoning
> > over the result of using none_of() with a user-defined predicate
> > gets quite difficult when compared against an all_of() or other
> > junction/multivalue objects.  Doing so against a single value is
> > much easier.
> >
> Yes but the documentation should say what combinations
> are potentially dangerous.

Dangerous?  Inefficient or useless, maybe, but dangerous?

> > I think "evaluate" is better than "is_true_that:"
> >
> >   if (evaluate(all_of(a), _1 >= _2, one_of(b))) ...
> >
> People who also code in scripting languages with
> an "eval" function would get confused.

I was actually thinking of that when I wrote it.  However, eval
usually has some value, though I think it is really just a status
code, not related to the expression being evaluated.

Perhaps we should consider a functional style:

   if (compare(all_of(a), one_of(b), _1 >= _2))

or

   if (compare(all_of(a), _1 >= _2, one_of(b)))

>  ________________________________________________________
> >   if (evaluate(all_of(a).where(filter1)
> >      , _1 >= _2
> >      , one_of(b).where(filter2)))
> >      ...
> >
> This may be also useful. Either specific filters for each side,
> or one common, or both or one or none.

For a common filter, you can just reuse it.

> > Nevertheless, the question arises whether all of this is
> > warranted.  Indeed, if we support iterator pairs in addition to
> > ranges, there are other libraries that one can employ to do the
> > filtering, so this one doesn't need to.
> >
> The filters could be lambdas. Result syntax could be smaller
> and easier to read then with another object (a filtering iterator).

That may be true, but I'm concerned about duplicating
functionality and, thus, limiting flexibility.  I guess we just
need to be sure that this library interoperates easily with
filters created using the facilities of the other libraries.

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