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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-08 21:47:29

From: FlSt_at_[hidden]
> Rob Stewart wrote:
> >From: Florian Stegner <FlSt_at_[hidden]>
> >>Rob Stewart wrote:
> >>
> >Nah, like this:
> >
> >   set<int> a;
> >   all_values<set<int> > all_of_a(all_of(a));
> >
> >I've nearly got that ready plus I'm using your dispatch
> >technique.  I'll upload it when I get it compiling.

I updated multivalues.zip
(http://boost-sandbox.sourceforge.net/vault/index.php?action=downloadfile&filename=multivalues.zip&directory=rob_stewart&).

This version uses your dispatch technique, supports iterators,
and provides user-level types such as all_value.  I also changed
n_m_of to use runtime values in preparation for implementing the
between and exactly stuff Pavel suggested.  I think this will
also reduce template instantiations and, thus, improve compile
times, at least a little.

> >>>2. You don't have iterator range support yet.
> >>>
> >>This will be the next point I will work on.
> >
> >Take a look at mine.  My next version will follow your dispatch
> >technique, so you might just want to wait for that one.
> >
> I will wait. :-)

Your wait is over! ;-)  Let me know what you think.

> >>>4. I see that you've made good use of implementing one type in
> >>>  terms of another.  I did that early on in my operator
> >>>  intensive version and ignored it after refactoring my
> >>>  library.  I need to revisit that.
> >>>
> >>That was the thing which makes the 10% runtime differences between our 
> >>implementations without optimizing.
> >
> >Mine is 10% faster or slower because of that?  I've lost track of
> >which is faster now.
> >
> Yours was faster.  I think my implementation of the do_comparison 
> functions for one_junction, n_junction, injunction and abjunction are 
> the reason.

Well, I'm still using separate loops.  We can consider
performance later.

> The operators with the highest precedence we can use are "*" "/" "%".... 
> I think "/" would look fine:
> all_of( a )  /expr()/ any_of(b).  But there is a little problem with 
> lambdas expressions using this operators. I tried following example:
> any_of( a ) |( lambda::_2 >= lambda::_1 )| all_of( b ). I got an error 
> message from gcc 4.0.1 that the call to the second |-operator is 
> ambiguous, because also lamda implements the | operator. How can this be 

Too bad the parentheses weren't enough.

> avoided? The only idea I have is the ","-operator. See below the error 
> message.

All we're after is visual separation and decent
interoperability.  Lambda overrides all overridable operators, so
I don't see how we can avoid the pain there.

There are many operators from which to choose, but I think we
should ensure we use one with higher precedence than the Boolean
operators.  Other than that, I think we just need an operator
that is esthetically pleasing to a wide range of folks.  Maybe we
even need more than one!

> Antoher point is the naming. I think, after reading a book about logic, 
> that "junction" would be the best name.

In a private message, I mentioned that "junction" or "junctor" is
appropriate only if what we're designing provides most everything
those names imply.  The other thing to consider is whether those
names are meaningful to most folks.  I know I wouldn't expect a
"junction" library to do what we're talking about.

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