Heinrich Apfelmus <apfel...@quantentunnel.de> wrote: > 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.
signature.asc
Description: PGP signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
