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

From: FlSt_at_[hidden]
Date: 2005-07-27 16:42:56

>>[...]
>>
>
>I got that book recently, but I haven't read it yet.  I just read
>his discussion of safe bool to be sure I knew to what you were
>referring.  The complexity is worthwhile, though it needn't be as
>complex as his solution
>
I found some simpler solutions, while searching the net. But this is an 
implementation detail, what we wanted to discuss later. It's on my memo.

>It's interesting to note that his use of the generator class is
>erroneous until he puts in a "workaround" for Borland.  On p404,
>he's still using "typedef boolean_type::return_type," but
>"return_type" is a dependent type, so standard C++ requires
>"typename" so his "workaround" was to make the code correct!
>
I didn't noticed that. This is a good reason to send him a mail to 
correct this in the next edition of his book or at least to add a 
comment why he did it so. I don't remember every datail. I will read 
this chapter a second time, before I go to bed tonight. ;-)

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

[...]

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

For example "a" contains 1, 2, 3 then the resulting junction of any_of( 
a ) >= all_of( a ) contains 3, which is the maximum value of a.

[...]

>I don't know what you mean by "adhere to the duality of the
>result of a comparison" unless you mean that your version always
>returns a new junction that can implicitly convert to a Boolean
>for comparisons.  I don't see the value of that.
>
See above.

>>[...]
>>
>>disjunction< Container > a, b;
>>
>>disjunction< Container > r = a <= b; // assign to another junction
>>
>
>[...]
>  
>
>>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 )

>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. ;-)

Florian