reactive-banana

I'm just starting to look into the world of Functional Reactive Programming in Haskell, and I would like to experiment with GUI programming (with gtk, because of substantial binding) in a reactional setting. Now, I've been looking a bit at Grapefruit, Reactive-Banana and Buster, and I would like any testament to the joy/horror of using any one or other package. All I have is these preliminary oppinions: I don't mind doing some of the binding of the FRP package to gtk myself, as I have an ambivalet feeling about the abstracted backend idea (that Grapefruit has).. While I find type theory

In recent implementations of Classic FRP, for instance reactive-banana, there are event streams and signals, which are step functions (reactive-banana calls them behaviours but they are nevertheless step functions). I've noticed that Elm only uses signals, and doesn't differentiate between signals and event streams. Also, reactive-banana allows to go from event streams to signals (edited: and it's sort of possible to act on behaviours using reactimate' although it not considered good practice), which kind of means that in theory we could apply all the event stream combinators on signals

This question is specific to reactive-banana and real-time simulations with a physical and visual component (eg., games). According to Fix Your Timestep! the ideal way to setup a game loop (assuming physics that needs to be reproducible), you need a fixed timestep between frames. After considering a number of real complications , the author arrives at this game loop: double t = 0.0; const double dt = 0.01; double currentTime = hires_time_in_seconds(); double accumulator = 0.0; State previous; State current; while ( !quit ) { double newTime = time(); double frameTime = newTime - currentTime; if

We have code like this: guiState :: Discrete GuiState guiState = stepperD (GuiState []) $ union (mkGuiState <$> changes model) evtAutoLayout evtAutoLayout :: Event GuiState evtAutoLayout = fmap fromJust . filterE isJust . fmap autoLayout $ changes guiState You can see that evtAutoLayout feeds into guiState which feeds into evtAutoLayout--so there is a cycle there. This is deliberate. Auto layout adjusts the gui state until it reaches an equilibrium and then it returns Nothing and so it should stop the loop. A new model change can kick it off again, of course. When we put this together, though,