Darren Grant wrote:

I have found Reactive Banana to be the most accessible so far. Still struggling with some of the language syntax though.

Are you struggling with the Haskell syntax, or with FRP in general or with any particular example? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

On Thu, Sep 20, 2012 at 2:09 AM, Darren Grant wrote:

Primarily Haskell syntax.

Would you like to try an experiment with me? Post one or two lines of code that's been really challenging for you, and let's see if we can't figure it out. The bar I'll set myself is not just explaining how it works but also figuring out to /say/ the code in plain English. How's that? -- Kim-Ee On Thu, Sep 20, 2012 at 2:09 AM, Darren Grant wrote:

Primarily Haskell syntax.

On Wed, Sep 19, 2012 at 8:18 AM, Heinrich Apfelmus wrote:

...

Darren Grant wrote:

...

I have found Reactive Banana to be the most accessible so far. Still struggling with some of the language syntax though.

Are you struggling with the Haskell syntax, or with FRP in general or with any particular example?

Best regards, Heinrich Apfelmus

-- http://apfelmus.nfshost.com

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

I don't know that netwire is more difficult to understand. I'm appreciating the network analogy and the generalisation of wires. Thanks for pointing it out! Cheers, Darren On Tue, Sep 18, 2012 at 7:35 PM, Ertugrul Söylemez wrote:

Christopher Howard wrote:

...

Which FRP framework (i.e., Haskell package) is the best one to play with for someone still trying to grasp the basics of FRP?

In terms of tutorials and related blog posts I currently recommend reactive-banana. In terms of power and elegance I recommend Netwire.

The main difference is that reactive-banana is both simple and easy. It implements classic FRP with the usual notion of behaviors and events. Heinrich strives to make it very accessible.

Netwire follows a more algebraic path and drops the classic notion. The line between signals and events is blurred. It's a bit more difficult to understand, but is more expressive and concise. Also it's pretty much time-leak-free. The library is designed to be very elegant while preserving non-FRP performance to a high degree.

(To be fair, I'm the author of 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.

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Miguel Negrao wrote:

...

Netwire follows a more algebraic path and drops the classic notion. The line between signals and events is blurred. It's a bit more difficult to understand, but is more expressive and concise. Also it's pretty much time-leak-free. The library is designed to be very elegant while preserving non-FRP performance to a high degree.

(To be fair, I'm the author of Netwire.) =)

Having recently looked a bit on Yampa, what are the main differences between Yampa and Netwire ?

The way events are handled. Yampa uses the classic automaton category with an additional time delta argument for its signal function representation (Yampa's type is more complicated, but isomorphic to this one): type Time = Double newtype SF a b = SF (Time -> a -> (b, SF a b)) Netwire generalizes this category to a class of wire categories (simplified and without associated types): newtype Wire e a b = Wire (Time -> a -> (Either e b, Wire e a b)) SF is an arrow and an applicative functor (although Yampa does not provide an Applicative instance). Wire is also an Alternative, which allows concise and efficient switching with very little cruft. The following wire renders "yes" when the "keyDown Space" event happens and "no" otherwise: pure "yes" . keyDown Space <|> pure "no" Or with the OverloadedStrings extension: "yes" . keyDown Space <|> "no" All classic (non-wire) FRP implementations need switching or another ad-hoc combinator for this. If you happen to need switching it's also a lot simpler using wires: "please press space" . notE (keyDown Space) --> "thanks" This one waits for the Space key and then outputs "thanks" forever. So far Netwire has the fastest and most elegant way of dealing with events compared to all other libraries I have tried. 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.

Heinrich Apfelmus wrote:

...

Wire is also an Alternative, which allows concise and efficient switching with very little cruft. The following wire renders "yes" when the "keyDown Space" event happens and "no" otherwise:

pure "yes" . keyDown Space <|> pure "no"

Or with the OverloadedStrings extension:

"yes" . keyDown Space <|> "no"

All classic (non-wire) FRP implementations need switching or another ad-hoc combinator for this. If you happen to need switching it's also a lot simpler using wires:

"please press space" . notE (keyDown Space) --> "thanks"

This one waits for the Space key and then outputs "thanks" forever. So far Netwire has the fastest and most elegant way of dealing with events compared to all other libraries I have tried.

These examples look neat!

I'm a bit confused about the model you are using, though. If I understand that correctly, you don't distinguish between events and behaviors; rather, you are working with data streams in discrete time steps. Still, I don't quite understand.

First let me try to put reactive-banana's model into a data type of my own, which you might call TimedZipStream. The name Behavior is easier, so let me pick that one instead (Time is the type for time deltas): newtype Behavior a = Behavior { stepBehavior :: Time -> Network (a, Behavior a) } This is not anywhere near how reactive-banana represents its behaviors, but just a simplified and less powerful model. The argument is the time delta to the last instant. Communication happens through the Network monad and is opaque to the user. The type is an applicative functor that represents values that can behave differently at each instant. My model is similar to Yampas model, where instead of time-varying values you have time-varying functions, so-called signal functions: newtype SF a b = SF { stepSF :: Time -> a -> (b, SF a b) } This is a function from an 'a' to a 'b' that mutates over time. There is a counterpart for classic behaviors, which is when the input type is fully polymorphic: time :: SF a Time SF forms a family of applicative functors, but now there is a direct path from one signal function to the next, because SF is itself a category. No graph, no monad, just plain categorical composition. Unfortunately to this day Yampa does not provide an Applicative instance, so you have to use the Arrow interface, which is usually very ugly. The weak spot of both models is events. They need to be handled using switchers and other combinators. Causality, simultaneity and choice all need to be encoded explicitly. Event modifiers work outside of the behavior level. What makes Netwire different? Wire categories are encoded by the following (simplified) type: newtype Wire e a b = Wire { stepWire :: Time -> a -> (Either e b, Wire e a b) } Wires can choose not to output anything, but instead inhibit with a value of type 'e'. Where i is an inhibiting wire the following identities hold: x . i = i i . x = i Furthermore now when 'e' is a Monoid Wire is a family of Alternative functors with the following identities, where x and y produce and i, j and ij' and inhibit: x <|> y = x i <|> y = y i <|> j = ij' The ij' wire also inhibits, but mappend-combines the inhibition values. The empty wire always inhibits with mempty. The monoid is necessary for the Category, Applicative and Alternative laws to hold.

What is

pure "yes" . keyDown Space <|> pure "no"

supposed to mean? If it's a function Time -> String , how long does it have the "yes" value? 439.7 milliseconds? If it's an event, how often does the "no" event fire?

An event wire is a wire that acts like the identity wire when it produces, but may choose to inhibit instead: pure "yes" . keyDown Space The 'keyDown Space' wire acts like the identity wire when the space key is pressed, otherwise it inhibits. As a consequence of the above laws the composition also inhibits. This is where (<|>) comes in: pure "yes" . keyDown Space <|> pure "no" When the left wire inhibits, the right wire takes over. By definition a 'pure' wire never inhibits. Notice that in this example I'm assuming that 'keyDown' is a 'continuous event'. That's where behaviors are mixed with events. An event can actually have a duration. If 'keyDown' would be instantaneous without a duration you could use the 'holdFor' combinator: pure "yes" . holdFor 1 (keyDown Space) <|> pure "no" This would also work for a continuous 'keyDown' event wire. Then if you press the space key for one second, "yes" is displayed for two seconds.

Concerning the other example, I don't understand what the expression

"please press space" . notE (keyDown Space)

means. If it's a function, what value does it have when the key was pressed? If it's an event, how often does it "fire" the string value?

In this case it doesn't really matter if 'keyDown Space' has a duration or not. As soon as it produces once, the switch happens and the next wire takes over. There is another name for the (-->) combinator called 'andThen'. x --> y As soon as x inhibits, this combination switches to y. Side note: Unlike classic FRP a wire category is not time-bound. In fact in the current official release of Netwire (3.1.0) time is actually an extension. In Netwire time is back as a primitive, because it makes time-related wires (the analog to behaviors) much easier to write. I have retained the flexibility that your wire can have a time frame different from real time, though. 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.

Thanks for the explanation! So, netwire is essentially based on the abstraction type Stoplight red green = Behavior' (Either red green) of time-varying values that can either be a "normal" value of type green , or an "exceptional" ("inhibiting") value of type red . (I have dropped the input dependence, so that arrow composition becomes normal function application.) Here, Behavior' denotes a type of continues time-varying values, with the small twist that it can "detect some flanks", namely when the value jumps from Right to Left . In this way, the flank can be interpreted as an Event in the reactive-banana sense. The applicative instance is the composition of the applicative instances for Behavior' and Either instance Monoid red => Applicative (Stoplight red) where pure x = pure (Right x) f <*> x = (<$)> <$> f <*> x if we assume that Either has the following applicative instance instance Monoid red => Applicative (Either red) where pure = Right (Right x) <*> (Right y) = Right (x y) (Left x) <*> (Right y) = Left x (Right x) <*> (Left y) = Left y (Left x) <*> (Left y) = Left (x <*> y) What I particularly like about this approach is the following: I like to think of Behavior as continuous functions, not necessarily because they are really continuous, but because this means that the semantics of Behavior is independent of any "update frequency", which is key point in simplifying code with FRP. Unfortunately, this means that we cannot "detect flanks", because a continuously changing Behavior simply does not change in discrete steps. The Stoplight type solves this problem by introducing an explicit "this is a flank" value, i.e. by using the fact that the only way an Either type can change is in discrete steps. Due to parametricity, I can't put this information into the general Behavior type, but the special case Behavior (Either red green) can make use of this. On the other hand, while the combination of Behaviors and Events allows for some slick switching combinators, I'm not entirely sure whether the mixture of two unrelated concepts (continuous functions vs singular occurrences) is too much of a conceptual burden. Best regards, Heinrich Apfelmus Ertugrul Söylemez wrote:

Heinrich Apfelmus wrote:

...

...

Wire is also an Alternative, which allows concise and efficient switching with very little cruft. The following wire renders "yes" when the "keyDown Space" event happens and "no" otherwise:

pure "yes" . keyDown Space <|> pure "no"

Or with the OverloadedStrings extension:

"yes" . keyDown Space <|> "no"

All classic (non-wire) FRP implementations need switching or another ad-hoc combinator for this. If you happen to need switching it's also a lot simpler using wires:

"please press space" . notE (keyDown Space) --> "thanks"

This one waits for the Space key and then outputs "thanks" forever. So far Netwire has the fastest and most elegant way of dealing with events compared to all other libraries I have tried. These examples look neat!

I'm a bit confused about the model you are using, though. If I understand that correctly, you don't distinguish between events and behaviors; rather, you are working with data streams in discrete time steps. Still, I don't quite understand.

First let me try to put reactive-banana's model into a data type of my own, which you might call TimedZipStream. The name Behavior is easier, so let me pick that one instead (Time is the type for time deltas):

newtype Behavior a = Behavior { stepBehavior :: Time -> Network (a, Behavior a) }

This is not anywhere near how reactive-banana represents its behaviors, but just a simplified and less powerful model. The argument is the time delta to the last instant. Communication happens through the Network monad and is opaque to the user. The type is an applicative functor that represents values that can behave differently at each instant.

My model is similar to Yampas model, where instead of time-varying values you have time-varying functions, so-called signal functions:

newtype SF a b = SF { stepSF :: Time -> a -> (b, SF a b) }

This is a function from an 'a' to a 'b' that mutates over time. There is a counterpart for classic behaviors, which is when the input type is fully polymorphic:

time :: SF a Time

SF forms a family of applicative functors, but now there is a direct path from one signal function to the next, because SF is itself a category. No graph, no monad, just plain categorical composition. Unfortunately to this day Yampa does not provide an Applicative instance, so you have to use the Arrow interface, which is usually very ugly.

The weak spot of both models is events. They need to be handled using switchers and other combinators. Causality, simultaneity and choice all need to be encoded explicitly. Event modifiers work outside of the behavior level.

What makes Netwire different? Wire categories are encoded by the following (simplified) type:

newtype Wire e a b = Wire { stepWire :: Time -> a -> (Either e b, Wire e a b) }

Wires can choose not to output anything, but instead inhibit with a value of type 'e'. Where i is an inhibiting wire the following identities hold:

x . i = i i . x = i

Furthermore now when 'e' is a Monoid Wire is a family of Alternative functors with the following identities, where x and y produce and i, j and ij' and inhibit:

x <|> y = x i <|> y = y

i <|> j = ij'

The ij' wire also inhibits, but mappend-combines the inhibition values. The empty wire always inhibits with mempty. The monoid is necessary for the Category, Applicative and Alternative laws to hold.

...

What is

pure "yes" . keyDown Space <|> pure "no"

supposed to mean? If it's a function Time -> String , how long does it have the "yes" value? 439.7 milliseconds? If it's an event, how often does the "no" event fire?

An event wire is a wire that acts like the identity wire when it produces, but may choose to inhibit instead:

pure "yes" . keyDown Space

The 'keyDown Space' wire acts like the identity wire when the space key is pressed, otherwise it inhibits. As a consequence of the above laws the composition also inhibits. This is where (<|>) comes in:

pure "yes" . keyDown Space <|> pure "no"

When the left wire inhibits, the right wire takes over. By definition a 'pure' wire never inhibits. Notice that in this example I'm assuming that 'keyDown' is a 'continuous event'. That's where behaviors are mixed with events. An event can actually have a duration.

If 'keyDown' would be instantaneous without a duration you could use the 'holdFor' combinator:

pure "yes" . holdFor 1 (keyDown Space) <|> pure "no"

This would also work for a continuous 'keyDown' event wire. Then if you press the space key for one second, "yes" is displayed for two seconds.

...

Concerning the other example, I don't understand what the expression

"please press space" . notE (keyDown Space)

means. If it's a function, what value does it have when the key was pressed? If it's an event, how often does it "fire" the string value?

In this case it doesn't really matter if 'keyDown Space' has a duration or not. As soon as it produces once, the switch happens and the next wire takes over. There is another name for the (-->) combinator called 'andThen'.

x --> y

As soon as x inhibits, this combination switches to y.

Side note: Unlike classic FRP a wire category is not time-bound. In fact in the current official release of Netwire (3.1.0) time is actually an extension. In Netwire time is back as a primitive, because it makes time-related wires (the analog to behaviors) much easier to write. I have retained the flexibility that your wire can have a time frame different from real time, though.

-- http://apfelmus.nfshost.com

A 20/09/2012, às 03:56, Ertugrul Söylemez escreveu:

Miguel Negrao wrote:

...

...

Netwire follows a more algebraic path and drops the classic notion. The line between signals and events is blurred. It's a bit more difficult to understand, but is more expressive and concise. Also it's pretty much time-leak-free. The library is designed to be very elegant while preserving non-FRP performance to a high degree.

(To be fair, I'm the author of Netwire.) =)

Having recently looked a bit on Yampa, what are the main differences between Yampa and Netwire ?

The way events are handled. Yampa uses the classic automaton category with an additional time delta argument for its signal function [...]

Thanks for the explanation. I was wondering, how would one translate this Yampa code into reactive-banana: fallingBall :: Pos -> Vel -> SF () (Pos, Vel) fallingBall y0 v0 = proc () -> do v <- (v0 +) ˆ<< integral -< -9.81 y <- (y0 +) ˆ<< integral -< v returnA -< (y, v) fallingBall’ :: Pos -> Vel -> SF () ((Pos,Vel), Event (Pos,Vel)) fallingBall’ y0 v0 = proc () -> do yv@(y, _) <- fallingBall y0 v0 -< () hit <- edge -< y <= 0 returnA -< (yv, hit ‘tag‘ yv) bouncingBall :: Pos -> SF () (Pos, Vel) bouncingBall y0 = bbAux y0 0.0 where bbAux y0 v0 = switch (fallingBall’ y0 v0) $ \(y,v) -> bbAux y (-v) Would it be possible to do this without dynamic event switching ? What about with the new event switching in v0.7 ? Also, is it possible (and is it easy ?) to do looping such as it is done in Yampa using the the loop arrow in reactive-banana/classic FRP ? best, Miguel Negrão

A 01/10/2012, às 09:49, Heinrich Apfelmus escreveu:

Miguel Negrao wrote:

...

Thanks for the explanation. I was wondering, how would one translate this Yampa code into reactive-banana: fallingBall :: Pos -> Vel -> SF () (Pos, Vel) fallingBall y0 v0 = proc () -> do v <- (v0 +) ˆ<< integral -< -9.81 y <- (y0 +) ˆ<< integral -< v returnA -< (y, v) fallingBall’ :: Pos -> Vel -> SF () ((Pos,Vel), Event (Pos,Vel)) fallingBall’ y0 v0 = proc () -> do yv@(y, _) <- fallingBall y0 v0 -< () hit <- edge -< y <= 0 returnA -< (yv, hit ‘tag‘ yv) bouncingBall :: Pos -> SF () (Pos, Vel) bouncingBall y0 = bbAux y0 0.0 where bbAux y0 v0 = switch (fallingBall’ y0 v0) $ \(y,v) -> bbAux y (-v) Would it be possible to do this without dynamic event switching ? What about with the new event switching in v0.7 ? Also, is it possible (and is it easy ?) to do looping such as it is done in Yampa using the the loop arrow in reactive-banana/classic FRP ?

The Animation.hs example may help

http://www.haskell.org/haskellwiki/Reactive-banana/Examples#animation

Essentially, the main difference is that reactive-banana doesn't have functions like integral or edge because they depend on an implicit time step. In reactive-banana, you have to manage time yourself, for instance by making a timer event from a wxTimer.

To calculate velocity and position, you can you use accumE on the timer event. To do collision detection, you can check whether the ball will move below the floor at each time step. Dynamic event switching is not needed here.

For a more complex example, have a look at Andreas Bernstein's paddle ball game

https://github.com/bernstein/breakout

Yes, looking at the internals of Yampa I had seen that they have internal time management, but my question was more specifically if there was a way to have a function like bbAux which recursively switches into itself. Would it be possible with the new dynamic switching ? I find that way of expressing the discontinuous changes quite elegant. Even more elegant seems to be the instantaneous impulses (modeling of distributions or dirac deltas) although I couldn’t find any functioning code that implements it [1]. The breakout game code you mentioned is an excelent example of FRP in use, and best of all, it actually compiles !! I’ve lost count of the FRP programs I’ve tried to compile without success (mostly yampa or YFRP related). It was very instructional to see how it implements this kind of game logic in reactiva-banana. It’s also a good example of recursive definitions in reactiva-banana: the ball velocity depends on the ball position and vice-versa. Thank you for the link and the explanations, Miguel [1] http://haskell.cs.yale.edu/wp-content/uploads/2011/01/icfp03.pdf bouncing :: Position -> SF () (Position, Velocity) bouncing y0 = proc () -> do rec y <- (y0 +) ^<< integralG -< yd_ni hit <- edge -< y <= 0 yd <- integralG -< -9.81 + impulse (hit ‘tag‘ (-2*leftLimit yd)) yd_ni <- assertNoImpulseG -< yd returnA -< (y, yd)