Dave Whipp noted:
> I think that the two proposals are equivalent, in the sense that either can
> be trivially implemented using the other.
Agreed.
> However, I am a little concerned that the transjunction "magically" changes
> an operator that returns a Boolean value into one that returns a list.
Technically, it turns the operator into one that returns a transjunction.
The "surprise" occurs because tranjunctions self-eigenvalue in a list context.
That's a huge convenience in direct usages, but not an essential component
of the proposal if indeed it proves too surprising in indirect usages.
However, if we did lose that feature then usages like:
say eigenvalues every(@number) < one(3,7);
sacrifices more than a little of the construct's original appeal, I think.
> If I wanted to write intentionally confusing code (which sometimes happens
> due to carelessness) then I might take advantage of the fact that C<every>
> is, in English, a synonym for C<all>, not C<any>:
>
> if every(@values) < one(3..7) {...}
Yes, Ted Z. pointed out to me that, as the name of this construct,
"every" has ambiguity and synonym issues. Other possibilities are:
select(@values) < one(3..7)
those(@values) < one(3..7)
whichever(@values) < one(3..7)
itemize(@values) < one(3..7)
extract(@values) < one(3..7)
...of which, only C<select> really seems a good alternative.
Any other suggestions most welcome!
Damian
