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) );


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).

Reply via email to