reactive-banana VS DefendTheKing

As I grew up on a Macintosh, I was always interested in graphical user interfaces. In my free time, I'm currently working on refreshing my reactive-banana library so that it will hopefully work well with the upcoming JavaScript backend. (The library relies on a few non-trivial garbage collector features, which were not implemented in GHCJS a decade ago. Essentially, I ended up with a program that gave different results, depending on whether it was compiled with GHC native or with GHCJS. 😅)

Another FRP implementation that I think is quite simple is reactive-banana. Heinrich recently refactored the module hierarchy to stratify it based on low-level, mid-level and high-level abstractions: https://github.com/HeinrichApfelmus/reactive-banana/tree/master/reactive-banana/src/Reactive/Banana/Prim

I agree! Having foldMap be available in a monadic context is a big win - here's an example of me asking for it in reactive-banana, along with a motivating example - https://github.com/HeinrichApfelmus/reactive-banana/issues/222. Library authors, please consider adding these instances - your users will thank you!

There are some examples that also use event-switching, like https://github.com/HeinrichApfelmus/reactive-banana/blob/master/reactive-banana-wx/src/BarTab.hs , which also seems to use execute. They use <$ though instead of <$>:

In COVID I polished and released my Python implementation of the game which I actually did years before the Haskell one, mainly because it kept working while my Haskell implementation bit-rotted due to my choice to use the library GLUT which has since stopped working.