Brent 'Dax' Royal-Gordon wrote:
The naive meaning of all of these would be::
any(map { @x[$_] = 7 } 4,3) all(map { @x[$_] = 7 } 4,3,2) one(map { @x[$_] = 7 } 1,2) none(map { @x[$_] = 7 } 1,2)
But I'm not sure the naive interpretation is correct.
A junction as an array index or hash key returns a junction of the corresponding elements/entries. So:
@x[4|3] = 7
is the same as:
any(@x[4], @x[3]) = 7
But I've repeated stated my strong belief that junctions are scalar values, *not* lvalues. So the result of that assignment ought to be:
Can't modify constant item in scalar assignment at demo.pl line 1
- Can you have non-scalar junctions?
Do junctive operators force scalar context on their arguments?
Yes.
If so, we know what happens (you get a junction of arrayrefs);
Yes.
if not, I suppose it's up for negotiation.
No. ;-)
- What does it mean to sort a list of junctions?
Brent's analysis is spot on, assuming that C<cmp> on junctions works as he envisaged. Personally, I think I'd implement C<cmp> as:
multi sub infix:<cmp> (Any|Junction $lhs, Any|Junction $rhs) {
return -1 if $lhs lt $rhs;
return 1 if $lhs gt $rhs;
return 0
}instead, but the differences are marginal: Brent's version treats junctions that can be equal or greater than as being equal; mine favours the inequality instead.
Ultimately, of course, a particular list of junctions may not be well-ordered at all. For example:
sort 1|10, 5|6, 11|0
in which *any* permutation of the list is a plausible sort. So sorting junctions isn't necessarily always meaningful.
Damian
