Is FRP a proper way to implement most "event-driven" things?

Question

In my very first impression of Haskell, it's a language can handle "execute-then-result" things amazingly well. But I can't find how to implement "event-driven" things like games, or HTTP/FTP/TCPSocket servers.

This question got answered after I read some papers about FRP, include Yampa and the FPS game created by it ( Frag ). It seems that the FRP is a nice model to implement "heavy" event-driven things like 3D game, but how about slighter event-driven applications like HTTP servers or normal desktop GUI programs ? What cons will appear if I use FRP to implement all these things ?

Answer 1

FRP is a very general technique and could almost certainly be used to implement anything that would normally use events. In the classical rendition of FRP, one of the core abstractions is the event. The difference is that instead of operating on events individually with callbacks, you operate on streams of events.

You should be able to render any normal event-driven code in terms of streams of events; the only difficulty would be in binding your streams with existing, external code like a GUI toolkit; however, this is more tedious than tricky. So I don't see any fundamental issue preventing you from using FRP anywhere you would use events in a different language.

In fact, I've had some good experiences using FRP for exactly what you call "lighter": simple GUI programs. I've used reactive banana with wxWidgets to write some very simple little graphical programs. I found the resulting code to be much simpler, easier to write and easier to read than the equivalent callback-based code would have been.

Reactive Banana can also be used for things like music, so it's clearly widely applicable. I haven't tried anything except GUI programming with it, but others have so it has to be possible.

Additionally, you should check out Elm which is an ML-style language for implementing web apps with FRP. It generates everything you need: HTML, CSS and JavaScript. I believe it even handles communication with the server. I haven't tried it, but it looks very nice.

So, people are clearly using FRP in a wide variety of domains, including ones that aren't "heavy". But this does not mean you should use it everywhere!

For one, it is possible to get unpredictable space and time behavior. I know that the creators of both Reactive Banana and Elm put a lot of effort into reducing these, but I suspect there is still some risk. I know I had some very odd space leaks when playing around with Reactive Banana WX, so it's certainly something to look out for. It might be harder to deal with these with FRP than with event-drive code you're used to working with. Of course, I've had inexplicable memory leaks with standard JavaScript, so non-FRP code isn't immune to this either!

Another consideration is that FRP may not be the best or clearest abstraction for your particular task. While it's great for things that have to be fully reactive, what about code that is very simple, like a web server? (I mean simple as in different requests probably do not interact too closely with each other.) I imagine having a web framework that handled large amounts of requests using a programming model based on FRP would be possible; I just don't think it would be optimal.

In fact, my understanding is that the GHC IO system is actually already event-driven under the hood, so you can write web servers in a standard programming style and get the benefits of using events for free. So, for web server code, a simpler underlying abstraction may be a better choice. I believe that's what existing frameworks like Snap and Yesod do--neither uses a reactive programming style, but both are still pleasant to use.

Answer 2

You do not need to use anything beyond "simple" Haskell to implement event driven games. I am currently writing a FPS using Haskell with the following (VERY high level) "architecture":

uiMake :: IO ([UIEvent],UIState)
uiTick :: UIState -> [ApEvent] -> IO ([UIEvent],UIState)

apMake :: ([ApEvent],ApState)
apTick :: ApState -> [UIEvent] -> ([ApEvent],ApState)

-- UIState = The state of the UI
-- ApState = The state of the application (game)
-- UIEvent = Key presses, screen resolution changes etc.
-- ApEvent = Entity movements etc.

It works great. No need for lenses, FRP or anything else "exotic".