On Wed, Apr 01, 2009 at 09:44:43AM -0400, Mark J. Reed wrote:
> The idea is that junctions should usually be invisible to the code,
> and autothreading handles them behind the scenes. [ ... ]
If I understand correctly, (which is by no means assured) a function
call with a junction as an argument generally acts as if it were
autothreaded. So:
$x = any(1,2,3);
$y = f($x);
should work like:
$y = any( f(1), f(2), f(3) );
Right?
sub f($x) {
return $x < 1.5 < $x ?? $x :: undef;
}
$y = f($x);
$z = $x < 1.5 < $x ?? $x :: undef;
Unless autothreading is also implied by conditionals, $y
and $z would have significantly different results; $y ===
any(undef,undef,undef) while $z === any(1,2,3). But, if
autothreading *is* implied by conditionals, where do the
threads get joined? I have a feeling that the autothreading
has to happen essentially at the point of the creation of the
junction to avoid getting a result from a junction that none
of the joined quantities is capable of justifying (such as
the one described ealier of (-4|4) matching the criteria to be
in the range 0..1). I suspect that juctions will be perl6's
"action-at-a-distance" hazard. (With quantum entanglement,
you get action-at-a-distance effects in the real world.
When we import them into a computer language, the resulting
action-at-a-distance should come as no surprise - except for
its inherent surprise/hazard nature.) Now, if it is acceptable
for -4|4 to return true for 0 <= $x <= 1 when tested directly
in an expression, but to return false if it is tested in a
subroutine, then perl6 junctions are not really modelling
quantum superpositions and I, at least, will need to find a
different metaphor for what they actually do do (and for what
they can be used for and when).
