Re: [Haskell-cafe] Announcement - HGamer3D - 0.2.1 - why netwire

Ertugrul Söylemez wrote:

Heinrich Apfelmus wrote:

...

I concur that chaining wires with the andThen combinator is very slick, I like it a lot. Wolfgang Jeltsch recently described a similar pattern for classical FRP, namely a behavior that doesn't live forever, but actually ends at some point in time, which can be interpreted as an event occurrence. ("It ends with a bang!")

Well, that would work, but I wonder why then you wouldn't want to go all the way to signal inhibition. You don't need AFRP to have it. It's actually quite a light-weight change. Allow behaviors not to produce a value, i.e. somewhere in your library replace "a" by "Maybe a".

I think that the andThen combinator is slick, but I'm not sure whether I find the underlying model -- signal inhibition -- to be equally pleasing. In the context of GUI programming, chaining several events with the andThen combinator is almost never needed, so I've postponed these questions for now.

...

How would you express the TwoCounters example [1] using dynamic event switching in netwire? (The example can be implemented without dynamic event switching, but that's not what I mean.) What about the BarTab example [2]?

I've been asked that via private mail. Let me just quote my answer:

"This is a misconception caused by the very different nature of Netwire. In Netwire everything is dynamic. What really happens in w1 --> w2 is that at the beginning only w1 exists. When it inhibits it is removed from the network and w2 takes its place. The missing ingredient is that w2 is not actually produced by a wire, but this is equally easy and natural. Just consider the context wires:

context id w

This wire will dynamically create a version of 'w' for every different input, so it acts like a router that will create wires if they don't already exist. Deletion works similarly:

contextLatest id 1000 w

This is a version that only keeps the 1000 latest contexts.

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, I would be interested in an implementation of the BarTab example [2] to compare the two approaches. [1]: http://conal.net/blog/posts/trimming-inputs-in-functional-reactive-programmi... [2]: http://www.haskell.org/haskellwiki/Reactive-banana/Examples#bartab Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com