Damian Conway wrote:
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).
Could thread termination without a return reasonably be treated as another way
of saying "returns nothing" or alternately returns an empty junction (a junction
ranging over zero values)? Or would that instead better be treated as an error
such that returning nothing should have been done explicitly? -- Darren Duncan
