Luke Palmer wrote:
Rod Adams writes:Hmm. I was thinking that the "eq" made it boolean context, but you're right, it doesn't collapse in this case.
Perhaps the easiest way to explain the difficulty here is to note thatIs that so? Does Perl6 have some fundamental law of junction preservation?
executing a relational op (i.e. returning a boolean) value on a junction
argument returns a junction of boolean values.
I would expect $matches to be either false or true---the junction values
are garbage collected.
You're both right.
The junction of junctions of bools gets created from the threading... and then gets collapsed into a single bool, based on the predicates.
Except that it doesn't. Not until it is evaluated in boolean context.
any(0, 1) does not immediately collapse to 1. Without any other
context, any(0, 1) means "any value which is either zero or one" and
interprets the boolean value of nothing. You wouldn't expect perl to
try to evaluate something as a boolean unless it's in some sort of
boolean context, would you? The same holds for junctions.
It's been established before that getting at _which_ values in a junctions made the evaluation turn one way or the other is _not_ something that will be readily supported.
I don't think that's been established. I think that's been stated as a
consequence of the current semantics. I don't see any linguistic reason
why junctions /should not/ support that. It's just that they don't
(right now).
I remember the topic coming up before during the "junction wars" of a few months ago. It was one of those things that separated junctions from sets in a rather dramatic way. And as you said, currently, they do not.
If you wish to propose syntax and semantics to make it happen, go for it. But the way I see it, in order to make that happen, you'd have to "remember" what value was threaded to generate each resulting value, and have that essentially be a property of that value. Then the return of a junction threading would be a rather more complex object, with possible chaining of these properties, if the junction goes through several iterations of evaluation. If you have that, it would be straightforward to write functions that inspect these properties, and grep out what you wanted.
My gut reaction though is that is gets expensive, and it seems odd to support this "value history" on only junctions. For instance, if you do "$x = isprime(4);", do you expect the resulting $x to have a property saying it was "derived from 4"? That's a philosophical matter. It would have some real nasty side effects on performance if done large scale, but could prove invaluable for debugging and some specific problems.
I think that if you want to know what matched, you should be using arrays and grep/map, not junctions.
-- Rod Adams
