# Re: simultaneous conditions in junctions

```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

\$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).
```