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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-02 12:42:01

From: "Pavel Vozenilek" <pavel_vozenilek_at_[hidden]>
> <FlSt_at_[hidden]> wrote:
> 
> ________________________________________________________
> 3. There should be overloads  of "xyz_of"
>    who take pair of iterators,
>    in the old-fashioned STL way.

Hmmm.  That's a good idea.  Ranges are nice, but they don't
support two iterators unless they are paired somehow.

> ________________________________________________________
> 4. Perhaps the could be rewritten not
>    to use macros as code generators.
> 
>    It is not possible to debug it as
>    it is now, for example.

That's a good point.  I've encountered the issue myself in my
implementation.

> ________________________________________________________
> 5. The classes like conjuction etc may be likely
>    moved into sub-namespace like boost::junction_details.

The idea is that you may wish to create and hold onto instances,
though I'll grant that most uses are likely to be via the *_of
function templates.

> ________________________________________________________
> 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) == ....

Those are possible but are they sufficiently useful?  Do you
think they would be used enough to justify creating/documenting
them?

>   exactly(10).items_of(a) >= ....

I already proposed n_of for that:

   n_of<10>(a)

That doesn't read as well as your version, of course.

> Comparison between two "mores" would be
> disabled.

Why?

> ________________________________________________________
> 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?  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.

I think "evaluate" is better than "is_true_that:"

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

Should the normal operators rely on lambda support?  My
implementation uses structs with templated operators to permit
heterogenous comparisons, so there's no need for lambda's heavy
lifting.

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

That doesn't sound like what you've described.  I'd expect this
to do what you've described:

   if (evaluate(all_of(a).where(filter1)
      , _1 >= _2
      , one_of(b).where(filter2)))
      ...

However, this would be even better as it wouldn't confuse
behavior:

   if (evaluate(all_of(from(a).select(filter1))
      , _1 >= _2
      , one_of(from(b).select(filter2))))
      ...

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.

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