Parallel iteration with optional break fails

[AndreVanDelft]

AboutIterations

koan(6)(
  """
  | `..?` in combination with a parallel operator may
  | model an unlimited group of processes each of which start
  | with an externally triggered action.
  """
) {
script..
  s = ..? & b c d

test(1) {runWithInput(s)(           ); thenActivatedOrSuccess(__`b,S`)}
test(2) {runWithInput(s)(b          ); thenActivatedOrSuccess(__`b,c`)}
test(3) {runWithInput(s)(b,b        ); thenActivatedOrSuccess(__`b,c`)}
test(4) {runWithInput(s)(b,b,c      ); thenActivatedOrSuccess(__`b,c,d`)}
test(5) {runWithInput(s)(b,b,c,d    ); thenActivatedOrSuccess(__`b,c`)}
test(6) {runWithInput(s)(b,c,b,d,c,d); thenActivatedOrSuccess(__`b,S`)}
}

Failures:

Test 5: Set(b) did not contain only (b, c)
Test 6: Set(b) did not contain only (b, S) (KoanSuite.scala:86)

[anatoliykmetyuk]

test(5) {runWithInput(s)(b,b,c,d ); thenActivatedOrSuccess(__b,c)}

This is not correct: c and d will trigger not one node but two nodes each, since they react to exact same event. So two b branches will terminate as a result, and a new one will be spawned. So b is the answer.

test(6) {runWithInput(s)(b,c,b,d,c,d); thenActivatedOrSuccess(__b,S)}

It would have been so if you used | instead of &. & has success only when all of its (infinite, in this case) children have success.

You can test hard cases on a debugger as this, by cloning it and writing expressions here, then running it and providing your input via the keyboard or buttons. Any lower case letters are allowed.

[AndreVanDelft]

Your comments are incorrect, with respect to the intention of what a "break?" should do in a parallel context. But that had not been specified precisely and clearly. It should be better now.
On a high level, it makes the group of operands activated after it optional.
But that leaves too many details.

I just improved the comments in ContinuationHandler.scala:

To define "more precisely" when “next activations” of parallel operators
happen, we consider their templates to be of the form

xi & break? & yi & break? & zi

Here xi etc stand for groups of operands that have no optional-breaks
activated; each group size is 0 or higher.
& stands here for any operator of: & && | || /

On activation xi and “break?” activate.
Activation continues with the next group (yi).

Then the second "break?" is activated. There are two possibilities:

• no atomic actions had been activated in yi.
  Then zi is activated, and maybe the next "break?" is activated etc.
• some atomic actions had been activated in yi.
  Then the yi are FTTB considered to be an "optional group", and activation stops.
  The optionality disappears as soon as an atomic action happens in yi;
  then also the activation resumes.

For the determination of successfulness of an and-parallel operator
the members an optional group of operands do not count.

[anatoliykmetyuk]

So what exactly is this problem? This expression behaves this way not only in the koans, but everywhere. Is that a problem on the core level, then? Should we move this issue to subscript repo?