StopTraversal behaviour not consistent in nested chains

[maxfischer2781]

The behaviour of StopTraversal is not consistent in send, nested or parallel execution. The described purpose is

• Stop the traversal of a path, with either
  • [1] No return value
  • [2] a final return value

Processing multiple sub-chains in chains fails to do [2], treating early return values as regular ones. A bundle behaves similarly.

A bare send will retry indefinitely in case of [1], until either a result is produced (regularly or via [2]) or StopIteration. This easily creates an infinite loop for inappropriate input, or non-defensive chains.

[maxfischer2781]

The major problem is consistently applying [2] in nested structures. This may require splitting the result list into active and final values. No idea for a consistent design that does not require chainlets to be aware of the split.

The behaviour of [1] could be adjusted for consistency with send: Breaking a flat chain should be consistent with a bare yield, producing None. This implies that breaking a forking chain produces an empty iterable, i.e. () or []. A StopIteration is not caught.

[maxfischer2781]

The functionality of [2] may be expressed with an explicit control structure. Instead of

a >> break_or_cont >> tail

an explicit switch as in

a >> either(break, cont >> tail)

[maxfischer2781]

Should be fixed since v1.3.0.