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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-25 13:00:32

From: FlSt_at_[hidden]
> >>
> >I have a few questions about your design:
> >
> >   Why "super position" versus Perl's "junction?"  When
> >   describing the enumerators, you use the Perl terminology,
> >   apparently because it makes sense.  Frankly, I don't "get"
> >   "super position."
> >
> Before it was a built-in feature of Perl, something similar was 
> available as a CPAN module called Quantum::SuperPosition. This naming 
> comes from the quantum physics where elementary particles can have more 
> than one state, called super position. But i think its more evident to 
> call it "junction". (Furthermore "super position" sounds overblown ;-)

I see.  I agree that "super position" sounds overblown for this
component.

> >   Why is the junction type a template parameter?  Did you
> >   consider making four separate types?  Does using one make it
> >   easier to compare instances of the four types?  Should the
> >   client have to care about that?  IOW, I think writing
> >   disjunction<T> is simpler and clearer than
> >   super_position<ANY, T>.  Other name possibilities like
> >   "any_of" are possible, too.
> >
> I must admit that i don't spend time in tinking about this until now. 

That's why we're here! ;-)

> The idea behind the diffrent types was, that i don't know how to handle 
> assignments between diffrent junction types.

Should there be assignment among them?

> I wrote an explicit 
> constructor for assigning the eigenvalues. But what should the 

I saw the use of eigenvalue in the code, but I don't see how it
is valid, given what little I know of linear algebra.  Anyway, I
understand that you're simply referring to the underlying state.

> assignment operator copy? Only the values or also the junction
> type?

I don't see the point of assigning a disjunction to an
abjunction, for example.  Once can use boost::any or some other
scheme to create a variant type when warranted.

> Would it be better to store the type as an attribute? An

That isn't needed if there isn't assignment between the four
types, right?

> another idea i
> had while writing this template class was, that i write a junction base 
> class and make the is_result_true(...) function virtual and inherit for 

That presumes that there is real commonality among these types.
As far as I can see, the only thing they have in common are
implementation details.  IOW, forgetting about construction,
destruction, and copying, all that they have in common is being
able to participate in comparisions, right?  That doesn't provide
a good basis for using virtual functions; there's no abstract
entity to model.

> every junction type. That would fit with your second naming suggestion, 

Are you referring to "any_of?"

> which i like, because its more conform to the Perl-implementation. I 

I think you're referring to "any_of" being similar to Perl's
"any," right?  I'm not worried about matching Perl's naming
conventions so much as choosing what is sensible.

Upon reflection, "any_of<T>" doesn't work so well as a type.  You
could use that as a family of function templates that generate a
disjunction<T>:

   template <typename T>
   disjunction<T>
   any_of(T const & v1);

   template <typename T>
   disjunction<T>
   any_of(T const & v1, T const & v2);

   etc.

> aggree that writing super_position<ALL,T> is ugly, not only for the 
> clients ;-). The comparisons between diffrent types is no problem, 
> because the only diffrence between the junction types is the 
> is_result_true() function. Has anyone an idea?

Don't do it! ;-)

> >   Why would one change the Container parameter?  Why would the
> >   client of this class care about the associative container
> >   being used to implement it?
> >
> I'm using boost::hash_set<T> in my own applications. And i think there 
> are cases where std::multiset<T> also can make sense. That was the 
> reason for this optional template parameter.
> For example this is not possible with std::set<T>: 
> http://www.metaperl.com/talks/p6-junctions/slide5.html

You should choose the best container for each of the four types
(assuming you agree to four separate types) so that each is as
efficient as you can make it.

A "one" junction might use std::multiset because you have to
allow for multiple elements of the same value so you can see if
there is only one.  OTOH, you could just count the number of each
element upon insertion.  Then, comparision means matching the
value and then checking the count.  Thus, lookup performance is
important and you don't need std::multiset for that.

"all," "any," and "none" have to check every element
(potentially). The O(log N) lookup of an associative container is
wasted.  A std::vector seems better suited to the task.  (The
only difference between them would be the condition that could
break the iteration.)

Unless one needs to be able to ask a junction for more
information like how many elements matching a given value it
holds or use it in set operations, their implementation should be
focused on just answering the one question you can ask of them.

Other considerations of these containers is what Concepts their
value type must satisfy.  Must the values be copyable?  Default
constructible?  These demands impact the range of types that may
be used.

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