From: FlSt@gmx.de
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.ta... 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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;