Martin D Kealey asked:

> Or do we not invert junctions, and run the risk of unexpected
> action-at-a-distance instead?

I think our current approach is correct. That is: we "invert"
junctions on operators that are themselves intrinsically inverted
(such as !=, !~~, !<), but do not invert on those that are not
(such as ==, ~~, >=). Or rather, we *never* invert junctions at all, but
merely honour the standard semantics of the prefix:<!> metaoperator:
hoisting the negation outside the entire operation and applying it
once the underlying operation is complete.

The apparent paradox you demonstrated with the two interpretations of
C<$foo < ($bar | $zot)> is due to the assumption (employed in
the second interpretation) that < is identical to !>=. Certainly that is
true for simple scalar numbers, but not always for vector types such as
tuples, sets, bags, complex numbers...or junctions. That doesn't make
either < or !>= intrinsically invalid on vector types (though they
obviously are inappropriate for *some* vector types); it just means you
can't reasonably treat the two operators as universally interchangeable,
just because they sometimes are.

In summary, the "problem" here seems to be that, algebraically,
junctions don't behave exactly like non-junctions. Which is true, but no
more a problem than the fact that, algebraically, complex numbers don't
behave exactly like non-complex numbers, or that sets don't behave
exactly like non-sets, or that Rats don't behave exactly like Nums,
which don't behave exactly like Ints, which don't behave exactly like
ints either.

And, of course, that's why Perl 6 has strong typing. So that, when these
differences in behaviour do matter, we can specify what kind(s) of data
we want to allow in particular variables, parameters or return
slots...and thereby prevent unexpected kinds of data from sneaking in and
violating (un)reasonable expectations or inducing (apparent) paradoxes. :-)

With regard to your other point:

> If it's about parallel data handling, then we have to be prepared to
> (notionally) fork the entire rest of the runtime, even as far as
> having a definition of what return value the parent process sees (from
> "exit") when those threads are implicitly collapsed at termination.

That's certainly true, although junctions are supposed to guarantee
to coalesce all the threads they may generate back into a single superimposed
result back in the originating thread.

The problem only arises if an operation or subroutine that has been
junctively threaded terminates without returning. But that's just
"having a side-effect", which we already know is inappropriate for
junctions (and hyperoperators, and autothreaded loops, and pretty much
any other kind of parallel construct).


Reply via email to