Ertugrul Söylemez wrote:

Heinrich Apfelmus wrote:

...

You said that reactive-banana didn't feel as simple after the introduction of dynamic event switching, though. Could you pinpoint some particular thing that made you feel like that? Maybe a type signature or a tutorial or something else? I took great care trying to make the dynamic event switching stuff entirely optional, so you can use reactive-banana without understanding it at all, but I'm not sure if I succeeded.

I think this is less of an issue with reactive-banana than with classic FRP in general. The type signatures of Netwire can be scary at first sight, but they are consistent throughout the entire library. Once you understand one of these type signatures you understand all of them. Once you know how to use one wire, you know how to use all others.

Let me pinpoint something in particular: events. In reactive-banana events are special, in Netwire they are not. This makes dynamic switching special in reactive-banana and natural in Netwire. Let me show you an example: You want to dispaly "one" for ten seconds, then "two" for twelve seconds, then start over:

myWire = "one" . for 10 --> "two" . for 12 --> myWire

Events and particularly dynamic event switching is one of the main problems Netwire solves elegantly. You can add this to reactive-banana, too, but it would require changing almost the entire event interface.

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!") However, do note that the andThen combinator in netwire can only be so slick because "switching restarts time" (as the documentation puts it). I don't see a nice way to switch between wires that have accumulated state. 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]? [1]: http://www.haskell.org/haskellwiki/Reactive-banana/Examples#twoCounters [2]: http://www.haskell.org/haskellwiki/Reactive-banana/Examples#bartab Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

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

Hi Heinrich: Its simply the types are more cumbersome, now. In netwire you basically have one type, which is "Wire ...." with some type parameters (underlying monad, inhibition type, in-type, out-type), When underlying monad and inhibition type is choosen, you can define a type synonym and all boils done to "GameWire a b" in all types, events (GameWire a a), behaviours (GameWire a b), what you want. Signal inhibition makes Events and Behviours looks equal. Also the overall network has this type. And by the way, no generalized datatypes (forall t. ....), which I'm also not too comfortable with. In reactive banana we have considerably more types then in netwire: - One tpye for Behaviours - One type for Events - sinks in addition: sinkoutput[text:==showNumber<$>result]- what is that? (I know it has something to do with feedback loops) - scary type for the network description: "forallt.Frameworkst=>Momentt()" best regards Peter

Peter Althainz wrote:

Hi Heinrich:

Its simply the types are more cumbersome, now. In netwire you basically have one type, which is "Wire ...." with some type parameters (underlying monad, inhibition type, in-type, out-type), When underlying monad and inhibition type is choosen, you can define a type synonym and all boils done to "GameWire a b" in all types, events (GameWire a a), behaviours (GameWire a b), what you want. Signal inhibition makes Events and Behviours looks equal. Also the overall network has this type. And by the way, no generalized datatypes (forall t. ....), which I'm also not too comfortable with.

In reactive banana we have considerably more types then in netwire:

- One tpye for Behaviours

- One type for Events

- sinks in addition: sinkoutput[text:==showNumber<$>result]- what is that? (I know it has something to do with feedback loops)

- scary type for the network description: "forallt.Frameworkst=>Momentt()"

Thanks Peter! The distinction between Behavior and Event is something fundamental that I don't want to give up easily. They behave differently under products and coproducts, they correspond to modalities in temporal logic and they are also very useful for recursion. Concerning the sink combinator, it's actually part of the GUI bindings and not of the core library. It's used to bind, say the text value of an edit widget to display the value of a Behavior String . Likewise, the forall t. Frameworks t => Moment t () type signature is used when binding to a GUI framework. The explicit forall is only used to be get the right name for the type t , usually you would just write Frameworks t => Moment t () . Overall, I like to think that the complexity is only superficial. I agree that the type parameter t is somewhat annoying, but it's necessary for fundamental reasons. Fortunately, it has a nice conceptual interpretation as "starting time". In the case of HGamer3D, the sink combinator would replace the need to declare a final "wire which runs all the wires at each step". It feels a bit weird to me to have wires like guiSetPropW that perform side effects, i.e. where it makes a different whether you observe their results or not. That's a complexity where I feel that something "has been swept under the rug". Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Hi Heinrich, Hi Ertugrul thanks for all your comments so far. In last e-mail, you wrote: Heinrich Apfelmus wrote:

In the case of HGamer3D, the sink combinator would replace the need to declare a final "wire which runs all the wires at each step". It feels a bit weird to me to have wires like guiSetPropW that perform side effects, i.e. where it makes a different whether you observe their results or not. That's a complexity where I feel that something "has been swept under the rug".

In particular imperative wires like guiSetPropW (or anything for which *set* is a sensible name) are simply wrong. A widget, e.g. a button, should look like this: type MyWire = WireM (Reader MyConfig) type MyEvent a = MyWire a a button :: MyEvent Button => A short explanation on the guiSetPropW wire: The guiSetPropW can be considered as being part of the GUI binding actually. It is in the public Api to overcome the limitation of not having all properties as single wires coded. Anyhow, if you want to act on something in the GUI (for example make a window visible or not) you will probably need something with a side effect. That is, where the guiSetPropW is used in the examples. But it is a little bit low level, the higher level wires look more nicer: for example, the button wire creation acutally looks like that: buttonW:: GUIElement -> GameWire a a with the button wire having the type of: GameWire a a It is a pure event wire, which gets fired, when the button is pressed. the "label" wire creation staticTextW :: GUIElement -> GameWire String String with the labe wire having the type of: GameWire String String the "editbox" wire creation: editBoxW :: GUIElement -> (GameWire a String, GameWire String String) creates two wires, one for getting notified on changes of the element: type: GameWire a String and one for setting a new value to the string: type: GameWire String String Here, I would be interested in your view. Of course you can make one wire out of it, but this has different consequences: - how to check for a change in the widget, if the wire is not executed, because no input value occur? - usually you need the output of the wire in different places of your final network where the input wire is needed, if you have only one wire this might be cumbersome, to code in combining the final network - and: yes, there has been also something swept under the rug here, because since both wires refer to the same GUI element, there is the same GUI element used inside, which is a reference. Actually this is somthing more OO/Scala like then Haskell but it works fine for me so far, since it does overcome the limitations of the points above. BR Peter