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

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2005-07-26 08:49:55

"Rob Stewart" <stewart_at_[hidden]> wrote in message 
news:200507251959.j6PJx7Qe022151_at_weezy.balstatdev.susq.com...

...

>> Perhaps part of the confusion is that "superposition" is a single word 
>> and
>> not two.
...
> It's still not very good at communicating the potential in this
> context.

Agreed.

>> So rather than creating new(as far as C++ is concerned) terminology, I'd
>> find general expansion of set manipulating functionality more useful.
>
> There are many things that one can do with more fundamental
> components.  The question is whether those things can be
> expressed better using a new component (where better can be
> interpreted variously).
>
> For example, using std::set where std::vector (or similar) works
> better is premature pessimism.  My last post on this subject
> suggested that the "all," "any," and "none" cases could be
> implemented using std::vector.  Putting such functionality on
> std::set means you pay with higher per-element overhead and
> slower iteration.
>
> In that case, rather than coercing std::set (or std::vector) to
> meet a new requirement, which enlarges its interface, you use it
> to provide the new behavior via composition.
>
> A junctions component also seems worthwhile because it raises
> one's awareness of the functionality and its possible
> application.  By contrast, one isn't likely to think of
> "junction" when looking for a solution to a problem.  Thus,
> adding the functionality to std::set, for example, is likely to
> put the functionality in a known component, increasing the
> chances one will see the functionality as a solution.

I associate Junction with the result of joining/connecting, such as already 
used by boost::thread and boost::signal.

I wasn't necessarily advocating expansion of std::set, but rather that the 
described functionality/behavior was more akin to the mathematical concept 
of a set. std::set carries additional baggage, notably the ordering, which 
is not always necessary. This conceptual_set may not even possess any 
internal storage at all. For example the set of odd numbers could be defined 
just as a function: bool ismember_odd_set( int n ){ return n % 2; }. Also as 
Darren Cooke mentioned in another post to this thread, ranges would be 
convenient, and is encompassed by the preceding concept. The key operations 
are defining sets, and comparing sets.

The Defining operations would include:

   conceptual_set s0(5);
   conceptual_set s1(4,5,6);
   conceptual_set s2(3,4,5);

   conceptual_set s3 = intersection( s1, s2 ); // {4,5}
   conceptual_set s4 =        union( s1, s2 ); // {3,4,5,6}

The easy comparison(==,!=) are:

    if( intersection(s0,s1) )
       std::cout << "uses operator bool to convey emptiness";

    if( intersection(5,s1) )
       std::cout << "implicit constructed {5}";

    if( union(s1,s2) == s3 )
       std::cout << "uses operator bool";

To avoid the unnecessary construction of temporaries when merely checking 
for emptiness, lazy evaluation could be used, ala phoenix/fusion.

The less than comparisons may require enumerating the members of a 
conceptual_set. I'm not sure how that would be accomplished in the case of 
odd_set above.

Jeff Flinn