Recursion is allowed if it is a mutual recursion between Behavior and Event . The best part about Behavior is that fetching them during the update will return the old value.
For example, 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 processing cycles be online?โ
As for your second question, are you looking for a filterE function and its cousins filterApply and whenE ?
As for your overall goal, I think it is rather ambitious. From the little experience that I have gained so far, it seems to me that linking to an existing structure seems completely different than creating a โcleanโ structure in FRP. Most likely, there are still undiscovered (but exciting!) Abstractions hiding there. I once started writing an application called BlackBoard , which contains a good abstraction about time-varying drawings.
However, if you care more about results rather than adventures, I would recommend a conservative approach: create an imperative-style GUI toolkit and grab a reactive banana to get the benefits of FRP.
If you just want some kind of GUI, I am currently focusing on the web browser as a GUI. Here are some preliminary experiments with Ji . The main advantage over wxHaskell is that it starts up and runs much easier, and any API development effort will benefit a very wide audience.
Heinrich apfelmus
source share