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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-26 13:37:26

From: "Jeff Flinn" <TriumphSprint2000_at_[hidden]>
> "Rob Stewart" <stewart_at_[hidden]> wrote in message 
> news:200507251959.j6PJx7Qe022151_at_weezy.balstatdev.susq.com...
> 
> >> 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).
[snip]
> > 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.

OK.  I wasn't married to "junction," but the "ab," "dis,"
etc. prefixes were helpful to distinguish among the behaviors.
However, "any," "all," "none," and "one" are even more
meaningful.

> 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 

I see.

> 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:
[snip] various set operations
> To avoid the unnecessary construction of temporaries when merely checking 
> for emptiness, lazy evaluation could be used, ala phoenix/fusion.

Yes, you'd want compile-time set operations where possible.

Let's compare notation.  Given a set of values usable by the
"any," "all," "none," and "one" types named s, a conceptual_set
named c, and a test value named x:

    "junctions" | conceptual_set
   -------------|-----------------------
   x == any(s)  | c.count(x) > 1
   x == all(s)  | c.count(x) == c.size()
   x == none(s) | c.count(x) == 0
   x == one(s)  | c.count(x) == 1

(I'm assuming that conceptual_set will provide count(), of
course.  Note that conceptual_set will probably include
contains(), so "any" could be written as c.contains(x).)

The junctions notation is shorter and clearer.

One can envision layering the junctions notation over
conceptual_set.

(The expositional implementation I've shown above is inefficient:
conceptual_set::count() can't know when you have enough
information to arrive at the answer.  For "any" and "one," you
can stop as soon as count > 1.  For "none," you can stop as soon
as count == 1.  For "all," you can stop as soon as an element
doesn't match.

You'd either have to make those operations be part of the
conceptual_set interface, or you'd have to implement them via
iteration.)

Implementation details aside, junctions--or whatever you want to
call them--seem like a good idea.

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