> In general I like where this is going but need a little hand holding > here- I'm not an expert on junctions or anything perl6- > >> So I'm going to go on to propose that we create a fifth class of >> Junction: the "transjunction", with corresponding keyword C<every>. > > It seems that by these definitions "every" isn't quite a junction-
It's an unordered collection of values that can be used like a single value, is parallelizable, and has an intrinsic associated operation. That's pretty much a junction. The only difference is that the associated operation is (in a sense) C<grep>, rather than C<&&>, C<||>, C<^^>, or C<!> > You'll need to specify "but not necessarily in the same order" if you > want junctive autothreading to work on "every" as it does with other > junctions. You're quite right. I should have been more specific about that. And, yes, I certainly do want to leave open the potential for parallel evaluation. > In which case it should probably be returning a junction > and not an ordered list. If you look at the implementation I appended, any comparison on a transjunction returns a transjunction. But it turns out to be much more useful if they also collapse to a list, which is why I implemented them as a role added to arrays/lists. > Which reminds me, .eigenvalues strictly speaking is a set and not a > list. Sure, but again, it's much more useful as a list. ;-) > And while I like the cleanliness of the "every" expressions I'm still > having trouble seeing why "every" should behave differently from > "any", "all". Maybe "every" isn't a junction? Maybe not, in the strictest sense. But it has many of the same characteristics and is extremely useful in many of the same kinds of ways as a duck^Wjunction. > Maybe junctions in general need to behave a little differently when > being compared against then they do now, so the need for "every" > goes away? Interestingly, that was how they were originally defined (back when they were called "Quantum::Superpositions"). Comparing a superposition produced a superposition of just those values for which the comparison was true. But I agree with Larry's decision to make junctions behave "normally" wrt comparisons. They're much easier to understand the way they are now. I am merely trying to reintroduce the useful extra concept of a collection of numbers that filters under comparisons. But if people aren't comfortable, I'm happy to leave it as a module (especially since it's already written). I would hate this (very worthwhile) discussion to distract from the key point of the original post: namely, that the private C<!eigenstates> is misnamed, and a public C<.eigenvalues> is missing. Damian
