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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-27 21:52:14

From: FlSt_at_[hidden]
> >
> >We have a fundamental disconnect that we must resolve.  If there
> >is or should be more to junctions than I've mentioned, I need to
> >understand the use cases and rationale.  It may also be that
> >you're trying to combine different concepts into the same set of
> >classes and we should tease them apart.
> >
> Maybe I'am. Perl 6 has a lot of new features, that I didn't know and 
> I'am more influenced by this Quantum::Superpositions module.
> You can download it from 
> http://www.cpan.org/modules/by-module/Quantum/Quantum-Superpositions-2.02.tar.gz 
> an take a look at the manual page.

I may do that, but from your comments later, I'm not sure I need
to.

> >>In the Quantum::Superpositions module manual page are examples to get 
> >>the min/max of a list in one line of code, which is based on the 
> >>resulting junction of a comparison:
> >>
> >>Minimum of a : any_of( a ) <= all_of( a )
> >>Maximum of a : any_of( a ) >= all_of( a )
> >
> >That's supported by my equality operator approach, too.
> >
> I doesn't see that, or I didn't unserstand something. Because the 

You'd write a <= operator that takes an disjunction and a
conjunction and then "Do the Right Thing(tm)."

However, as Darren Cook commented, there is a more
straightforward way to get the maximum element from a range.

> resulting junction of any_of( a ) <= all_of( a ) contains the minimum 
> value of a. Probaly there are more expressions like this, where the 
> resulting junction contains values which are useful. That's why I like 
> to have a result junction besides the boolean result value.

I don't see the need.

> >>Container r_c = a <= b; // use values of the resulting junction ( if 
> >>junctions are refs, then this isn't necessary )
> >
> >Why?
> >
> See above. At least one of them is useful. Returning a new junction as 
> result would make possible to write something like this:
> 
> ( any_of( a ) >= any_of( b ) ) <= any_of( c )
> 
> Or if the comparison returns an container:
> 
> any_of( any_of( a ) >= any_of( b ) ) <= any_of( c )

Why would you write those?  What do they mean?

Assuming your behavior, I think the first is supposed to be those
elements of a that are greater than any one of the elements of b
that are also less than any one of the elements of c.  IOW, the
elements of a that are greater than the smallest element of b and
less than the largest element of c.  That would certainly be
easier to understand if written like this:

   (any_of(a) >= min_element(b)) <= max_element(c)

That version uses a few more characters, but it is more obvious,
don't you think?

If that is a useful expression, it's more of a set operation than
a junction operation (as exemplified by Perl's junctions) anyway,
right?  Besides, normal algorithms can be used to express that
quite succinctly.  Do you need a new type for it?  Maybe.  I
don't think it should be merged with the simpler ideas from Perl
junctions.  I think they are orthogonal behaviors, and the
complexity argues against one type doing both tasks.

> >If we can agree to forgo the arithmetic functionality you've
> >thought should be part of the junction classes, we can simplify
> >the design significantly.  That, in turn, will make writing
> >documentation easier and will increase the chances of acceptance
> >into Boost.
> >
> Ok, let's forget the arithmetic functionality. You're right, that I was 
> trying to combine more than one concept. That was the influence of Perl 
> and this Quantum::Superpositions module. ;-)

Good.  That's a step in the right direction, I think.  Removing
the junction result type--your duality idea--will further
simplify things.  This still leaves all of the comparisons among
the different junctions types as well as with non-junction types.
That is a great deal of functionality by itself.

BTW, I don't want to completely discourage your other ideas.
They may be appropriate for separate libraries, but I think you
should develop them apart from junctions.

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