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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-01 20:14:44

From: FlSt_at_[hidden]
> Rob Stewart wrote:
> >  
> >  That has raised some questions, but first, I have an idea for the
> >naming:
> >
> >   namespace: boost::multivalues
> >   base class: multivalue
> >   all_of: all_values
> >   any_of: any_value
> >   none_of: no_values
> >   one_of: one_value
> >
> Sounds a bit like a container type for me. It's nothing more than a 
> functional extension for ranges (or container), some kind of algorithm. 
> I don't know!

It does sound a little like a container type, but what container
would be named like those?  That is, I don't think they would
make good container names, so I think they fit our purposes
reasonably well.

I'm hoping someone else will jump in soon enough with other
suggestions since the release furor is mostly past now.  Still, I
do like these names.

> >Are all (in)equality comparisons symmetric?  I was pondering what
> >the following expression means:
> >
> >   any_of(s1) == one_of(s2)
> >
> I understand xxx_of as giving a logical linkage to the values of a list 
> and I think this is what Perl also does:
> all_of  = and, any_of = or, one_of = xor and none_of = not any_of. Do 
> you agree?

I'm not certain I can agree.  I understand that using that
definition does simplify the implementation, but "all" doesn't
quite evoke "and," nor "any" "or," nor "none" "not."  "one" does
reasonably evoke "xor," however.

I didn't pay enough attention to the details of the Perl
approach, so I didn't get mired in them.  That left me to
interpret "all," "and," "none," and "or" at face value.  That
also left me to find some strange combinations that were
confusing.  (More below.)

> false   <---- different result! This is the proove that in my 
> interpretation not all equality comparisons are symetric

I think allowing asymmetry in these expressions will cause great
confusion.  This is especially true when it isn't required.

> I hope the explanation of my interpretation of junctions was evident. 

Yes.  I'd forgotten the Perl equivalencies to AND, OR, XOR, and
NOT.

> (It's difficult for me writing texts in englisch, reading is easier for 
> me ;-)

You're doing quite well.  I'm sure I would do quite poorly in
your native language!

> >When written that way, it seems easy to think that there should
> >only be one value in s1 that matches a value in s2.  IOW, if more
> >than one value in s1 matches exactly one value in s2, the
> >expression would be false.
> >
> >Thus, the first expression could also be true iff there is just
> >one value in s1 that matches exactly one value in s2.
> >
> >If you think the latter interpretation, then how does that differ
> >from the following expression?
> >
> >   one_of(s1) == one_of(s2)
> >
> >That expression clearly says exactly one value in s1 must match
> >exactly one value in s2.  Consequently, I think it argues for the
> >first two expressions to be true if one or more value in s1
> >matches exactly one value in s2.  Do you agree?
> >  
> See above. This should answer all questions if you agree with me of what 
> the junction comparison does.

I think it would be more sensible when read, and remains easy
enough to explain if we provide symmetry and these definitions:

   all_of: every value must satisfy the test with the same other
      value
   any_of: at least one value must satisfy the test
   each_of: every value must satisfy the test
   n_of: exactly n values must satisfy the test
   none_of: no value may satisfy the test
   one_of: exactly one value must satisfy the test

I invented n_of (n_values) when I was considering none_of and
one_of and I thought to generalize it.

all_of is different from the others in that all of the values
have to satisfy the test against the same other side.  That is,

   all_of(x) OP any_of(y) means all values in x must OP the same
      value in y
   all_of(x) OP each_of(y) means all values in x must OP every
      value in y
   all_of(x) OP n_of(y) means all values in x must OP the same N
      values in y
   all_of(x) OP none_of(y) means all values in x must OP no
      values in y
   all_of(x) OP one_of(y) means all values in x must OP the same
      one value in y

The same applies when you reverse the arguments.

For the one_of(x) == one_of(y) example, I think it is reasonable
to think of it as finding exactly one value from x and exactly
one from y that satisfies x[n] == y[m].  That's how it reads.  (I
haven't even attempted to see whether that's how your
interpretation would answer.)

> There are some combinations of "xxx_of(s1) OP yyy_of(s2)" which are not 
> useful. I think it would be a good idea to extract useful and not so 
> useful expressions and document it. At the first sight it seems that 

I don't think there's a need to document what isn't useful.  If a
combination is never satisfied or is more efficient if expressed
another way, we can implement them on behalf of the user
accordingly.  That is, if a combination is never true, we can
define it to just return false.  If a combination is inefficient
and it can be expressed more efficiently, we can forward to the
efficient implementation.  (My design makes that simple to do.)

> junctions (multivalues) are trivial, but i must admit they aren't.

Indeed.

I have to review my design to make sure I'm doing everything
correctly, and I have a couple of tests that fail still.  Once I
finish, I'll upload it for your inspection.

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