Premature end of Chain traversal

[maxfischer2781]

With separate Chains and Links, there is currently no way for a Link to signal an end of chain traversal. This makes filters impossible, and thus makes future loops questionable.

There are two situations for aborting the traversal of a chain:

• A producer is exhausted, and the chain can never be traversed again. For symmetry with chains as generators, the StopIteration is appropriate.
  • This may require chains to remove subchains that are exhausted, as long as there are other, parallel chains that are not exhausted. A chain would re-raise StopIteration if there are no more subchains.
• An element decides to block further traversal based on its current data chunk, but may be traversed again with other input. A new exception, StopTraversal, is suggested.
  • This exception should not "bubble up" to iterations. A separate interface for traversal and iteration may be needed.
    • The public interface should remain as send and __next__, since this is used by external iteration. It uses traversal, but filters out any internal exceptions.
    • An internal interface for traversal should be added, e.g. as visit(value=None), or a conventional chain_* (chain_send), link_*, c*.

[maxfischer2781]

Now using a StopTraversal exception. Only downside is that n->1 and 1->1 generators cannot stop traversal.

There is still some unclear semantics for stopping inside a nested chain with return value.

[maxfischer2781]

Current approach seems to work well enough in practice. Lack of generator/coroutine support is unfortunate, but class based approaches work well as replacements.

Stop+return in nested chains seems ambiguous either way. Staying with the current approach, which is the most efficient. Whether to advance or not can be influenced by putting later elements into the nested or enclosing chain.