Heinrich Apfelmus
So context has the same purpose as Conal's trim combinator [1]. However, I believe that it is too inconvenient for managing very dynamic collections that need to keep track of state, as the context function significantly limits the scope of the stateful wire. That's why I've opted for a more flexible approach in Reactive.Banana.Switch , even if that introduces significant complexity in the type signatures.
Again you are thinking in primitive combinators. Keep in mind that context is nothing primitive. In earlier releases of Netwire I had a "manager" wire that allowed to manage a set of running wires by message passing. However, that wire turned out to be either too generic or too specific. There was no good balance, so I decided to get rid of it altogether. Now every library layer or application would write its own application-specific manager wire.
Again, I would be interested in an implementation of the BarTab example [2] to compare the two approaches.
I'm happy to provide one. Please be patient until I release netwire-vty, a terminal UI library based on Netwire. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.