Recursion is allowed, as long as it is mutual recursion between a Behavior
and an Event
. The nice thing about Behavior
s is that sampling them at the time of an update will return the old value.
For instance, your example can be expressed as follows
eClick1, eClick2 :: Event t ()
bCounter :: Behavior t Int
bCounter = accumB 0 $ mconcat [eIncrement, eReset]
eIncrement = (+1) <$ eClick1
eReset = (const 0) <$ whenE ((> 0) <$> bCounter) eClick2
See also the question "Can reactive-banana handle cycles in the network?"
As for your second question, you seem to be looking for the function filterE
and its cousins filterApply
and whenE
?
As for your overall goal, I think it is quite ambitious. From what little experience I have gained so far, it seems to me that binding to an existing framework feels quite different from making an "clean-state" framework in FRP. Most likely, there are still some undiscovered (but exciting!) abstractions lurking there. I once started to write an application called BlackBoard that contains a nice abstraction about time-varying drawings.
However, if you care more about the result rather than the adventure, I would recommend a conservative approach: create the GUI toolkit in an imperative style and hook reactive-banana on top of that to get the benefits of FRP.
In case you just wish for any GUI, I am currently focussing on the web browser as a GUI. Here some preliminary experiments with Ji. The main benefit over wxHaskell is that it's a lot easier to get up and running and any API design efforts will benefit a very wide audience.