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

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2005-08-03 07:08:10

"Rob Stewart" wrote:

>>   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.
>
You are right. Seems my deductive thinking
isn't as strong as I always thought.

 ________________________________________________________
>> >>   if ( is_true_that(all_of(a), a_binary_functor, one_of(b)) ) ...
>
> 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.
>
No, the (2) should be true if any value from 'a'
cannot be equaled to some single value from 'b'.
This would make it symetrical to (1).

Say:
  a = green, blue, blue
  b = blue, red

  none_of(a) == any_of(b)
is false because there is blue (even 2 of them)
from 'a' that match something in 'b'

  any_of(a) == none_of(b)
is false because there are two different cases
when blue from 'a' is in 'b'.

Not because 'b' lacks  2 blues.

IOW any_of() should care about cardinality.

For the
   any_of(s1) == one_of(s2)
   one_of(s2) == any_of(s1)

I think the "one_of" should read as
   "exactly_one_and_only_one_of"
and "any_of" as
   "any_individual_item_of"

This should restore the symetry.

This is my understanding how these qualifiers should
be implemented and thought about. The other
interpretation didn't occured to me but perhaps I am
still missing the 'aha!' moment.

I didn't study the implementation deep enough
(I would need to step through) but it should be
symetrical.

> Perhaps we should consider a functional style:
>
>   if (compare(all_of(a), one_of(b), _1 >= _2))
>
That would be

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

woudn't it?

 ________________________________________________________
>> >   if (evaluate(all_of(a).where(filter1)
>> >      , _1 >= _2
>> >      , one_of(b).where(filter2)))
>> >      ...
>> >
> 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.
>
IMO syntax should decide what to use.

If  filter iterator is as easy to use as hypothetical
embedded filter than I am all for for it.

Expression that could be written on single line
it is much prefered to alternatives:

vector<int> a;
set<int> b;

if ( is_true_that(any_of(a), _1 * 2 >= _2, all_of(b)).where(_1 >= 0 && _2 > 
10) ) {

is still somehow readable (as long as the filter is simple).

/Pavel