Is functional GUI programming possible?

Question

I've recently caught the FP bug (trying to learn Haskell), and I've been really impressed with what I've seen so far (first-class functions, lazy evaluation, and all the other goodies). I'm no expert yet, but I've already begun to find it easier to reason "functionally" than imperatively for basic algorithms (and I'm having trouble going back where I have to).

The one area where current FP seems to fall flat, however, is GUI programming. The Haskell approach seems to be to just wrap imperative GUI toolkits (such as GTK+ or wxWidgets) and to use "do" blocks to simulate an imperative style. I haven't used F#, but my understanding is that it does something similar using OOP with .NET classes. Obviously, there's a good reason for this--current GUI programming is all about IO and side effects, so purely functional programming isn't possible with most current frameworks.

My question is, is it possible to have a functional approach to GUI programming? I'm having trouble imagining what this would look like in practice. Does anyone know of any frameworks, experimental or otherwise, that try this sort of thing (or even any frameworks that are designed from the ground up for a functional language)? Or is the solution to just use a hybrid approach, with OOP for the GUI parts and FP for the logic? (I'm just asking out of curiosity--I'd love to think that FP is "the future," but GUI programming seems like a pretty large hole to fill.)

Solution 1

The Haskell approach seems to be to just wrap imperative GUI toolkits (such as GTK+ or wxWidgets) and to use "do" blocks to simulate an imperative style

That's not really the "Haskell approach" -- that's just how you bind to imperative GUI toolkits most directly -- via an imperative interface. Haskell just happens to have fairly prominent bindings.

There are several moderately mature, or more experimental purely functional/declarative approaches to GUIs, mostly in Haskell, and primarily using functional reactive programming.

Some examples are:

• reflex-platform, https://github.com/reflex-frp/reflex-platform
• grapefruit, http://hackage.haskell.org/package/grapefruit-ui-gtk
• reactive, http://hackage.haskell.org/package/reactive-glut
• wxFruit, http://hackage.haskell.org/package/wxFruit
• reactive-banana, http://hackage.haskell.org/package/reactive-banana

For those of you not familiar with Haskell, Flapjax, http://www.flapjax-lang.org/ is an implementation of functional reactive programming on top of JavaScript.

Solution 2

My question is, is it possible to have a functional approach to GUI programming?

The key words you are looking for are "functional reactive programming" (FRP).

Conal Elliott and some others have made a bit of a cottage industry out of trying to find the right abstraction for FRP. There are several implementations of FRP concepts in Haskell.

You might consider starting with Conal's most recent "Push-Pull Functional Reactive Programming" paper, but there are several other (older) implementations, some linked from the haskell.org site. Conal has a knack for covering the entire domain, and his paper can be read without reference to what came before.

To get a feel for how this approach can be used for GUI development, you might want to look at Fudgets, which while it is getting a bit long in the tooth these days, being designed in the mid 90s, does present a solid FRP approach to GUI design.

Solution 3

Windows Presentation Foundation is a proof that functional approach works very well for GUI programming. It has many functional aspects and "good" WPF code (search for MVVM pattern) emphasizes the functional approach over imperative. I could bravely claim that WPF is the most successful real-world functional GUI toolkit :-)

WPF describes the User interface in XAML (although you can rewrite it to functionally looking C# or F# too), so to create some user interface you would write:

<!-- Declarative user interface in WPF and XAML --> 
<Canvas Background="Black">
   <Ellipse x:Name="greenEllipse" Width="75" Height="75" 
      Canvas.Left="0" Canvas.Top="0" Fill="LightGreen" />
</Canvas>

Moreover, WPF also allows you to declaratively describe animations and reactions to events using another set of declarative tags (again, same thing can be written as C#/F# code):

<DoubleAnimation
   Storyboard.TargetName="greenEllipse" 
   Storyboard.TargetProperty="(Canvas.Left)"
   From="0.0" To="100.0" Duration="0:0:5" />

In fact, I think that WPF has many things in common with Haskell's FRP (though I believe that WPF designers didn't know about FRP and it is a bit unfortunate - WPF sometimes feels a bit weird and unclear if you're using the functional point of view).

Solution 4

I would actually say that functional programming (F#) is much better tool for user interface programming than for example C#. You just need to think about the problem a little bit differently.

I discuss this topic in my functional programming book in Chapter 16, but there is a free excerpt available, which shows (IMHO) the most interesting pattern that you can use in F#. Say you want to implement drawing of rectangles (user pushes the button, moves the mouse and releases the button). In F#, you can write something like this:

let rec drawingLoop(clr, from) = async { 
   // Wait for the first MouseMove occurrence 
   let! move = Async.AwaitObservable(form.MouseMove) 
   if (move.Button &&& MouseButtons.Left) = MouseButtons.Left then 
      // Refresh the window & continue looping 
      drawRectangle(clr, from, (move.X, move.Y)) 
      return! drawingLoop(clr, from) 
   else
      // Return the end position of rectangle 
      return (move.X, move.Y) } 

let waitingLoop() = async { 
   while true do
      // Wait until the user starts drawing next rectangle
      let! down = Async.AwaitObservable(form.MouseDown) 
      let downPos = (down.X, down.Y) 
      if (down.Button &&& MouseButtons.Left) = MouseButtons.Left then 
         // Wait for the end point of the rectangle
         let! upPos = drawingLoop(Color.IndianRed, downPos) 
         do printfn "Drawn rectangle (%A, %A)" downPos upPos }

This is a very imperative approach (in the usual pragmatic F# style), but it avoids using mutable state for storing the current state of drawing and for storing inital location. It can be made even more functional though, I wrote a library that does that as part of my Master thesis, which should be available on my blog in the next couple of days.

Functional Reactive Programming is a more functional approach, but I find it somewhat harder to use as it relies on quite advanced Haskell features (such as arrows). However, it is very elegant in a large number of cases. It's limitation is that you cannot easily encode a state machine (which is a useful mental model for reactive programs). This is very easy using the F# technique above.

Solution 5

Whether you're in a hybrid functional/OO language like F# or OCaml, or in a purely functional language like Haskell where side-effects are relegated to the IO monad, it's mostly the case that a ton of the work required to manage a GUI is much more like a "side effect" than like a purely functional algorithm.

That said, there has been some really solid research put into functional GUIs. There are even some (mostly) functional toolkits such as Fudgets or FranTk.

View more solutions

Comments

[new123456]

Having looked at GUI's in Common Lisp and OCaml, I would say that, more likely, its Haskell's laziness that's causing the issue.

[Electric Coffee]

@new123456 Common Lisp isn't a functional language though, it works with mutable data and embraces side effects

[Admin]

haskell.org/haskellwiki/Functional_Reactive_Programming for a list of GUI libraries

[chrismamo1]

@ElectricCoffee Lisp is an extremely flexible language capable of being used in many different styles, and many people choose to use Lisp in a functional style.

[AlexG]

From my experience (though I'm still trying to believe in it and learning more) FRP really reaches its limit with GUI programming; it's nice and elegant for 80% of the uses cases but rich widgets require very precise control of their internal state (e.g search combo boxes, etc) and FRP just gets in the way. Imperative is not always evil; trying to minimize the amount of imperative code is good but removing 100% of it ? Have yet to see it work for non trivial UI development.

[Totti]

@ElectricCoffee "Common Lisp isn't a functional language though". Lisp is the mother of all functional languages. You mean Lisp isn't pure.

[luqui]

See Conal Elliott's paper about fruit for a great, in-depth description of the technique and the decisions: conal.net/papers/genuinely-functional-guis.pdf I have been doing purely functional GUI programming in this style for a few months now. I LOVE it, it is such a pleasant relief from the spaghetti hell of imperative UI programming, which seems to be worse in this respect than most imperative programming.

[shosti]

Excellent, that's exactly what I was looking for--looks much more interesting than the imperative approaches I've seen (for instance in Real World Haskell). I'll definitely be checking out various FRP libraries.

[Jörg W Mittag]

I 100% agree with this. To make it crystal clear: the reason why existing GUI toolkits are often used is because they exist. The reason why interfaces to them tend to be imperative and impure is because the toolkits tend to be imperative and impure. The reason why the toolkits tend to be imperative and impure is because the operating systems they depend on tend to be imperative and impure. However, there's nothing fundamentally requiring any of these to be impure: there's functional bindings for those toolkits, there's functional toolkits, there are even functional operating systems.

[Jörg W Mittag]

It's all just a matter of laziness. (Bad pun intended.)

[BlueRaja - Danny Pflughoeft]

Someday all GUI design will be implemented via WYSIWYG, with the logic implemented functionally. This is my prediction.

[Dan Burton]

"functional GUIs" link broken :( cached: webcache.googleusercontent.com/search?q=cache:http://…

[Totti]

+1 This reflects our experience, having written several production GUIs in F# using combinator libraries and IObservable.

[Rei Miyasaka]

Jorg: Sounds exciting. Can you give me an example of a functional operating system?

[aganders3]

The paper luqui mentions seems to be dead. There is a working link on Conal Elliott's site, though: conal.net/papers/genuinely-functional-guis.pdf

[Tikhon Jelvis]

I think you misunderstood the point: it's not that functional programming has no outside effect on the world--that would make all programs entirely useless! Rather, functional programming lets you quarantine the IO so you know which bits use it and which bits don't.

[CoR]

That link is broken for a long time. Try this Yampa

[pyCthon]

the only one that seems to be "up to date" is reactive-banana

[Fsharp Pete]

Has the comment on FRP changed since the introduction of reactive extensions to the .NET library?

[devuxer]

While XAML is very declarative in nature, does MVVM really encourage a functional style of programming? The whole notion of a view model, whose job is to track the state of the view (and implements an interface called INotifyPropertyChanged of all things), seems antithetical to FP to me. I'm definitely no expert on FP, and maybe I'm focusing too much on the immutability aspect as opposed to the declarative aspect, but I'm having trouble seeing how the MVVM pattern (as typically used) is an example of FP.

[Luaan]

@devuxer I would argue that it does. I don't think anyone would realistically use FP for strict immutable code. Instead, you decide where your mutability boundaries are, and work immutable on all the other levels - in this case, everyone can assume the state is immutable, except for that single tiny part that actually mutates the state. It's similar to how HTML works - yeah, you've got the immutable DOM, but whenever you navigate, you still have to build a new one. INotifyPropertyChanged is just an update function you pass to wherever you need to handle the GUI updates - it's a latency fix.

[Erik Kaplun]

Here's some research on Arrowized FRP and how effects and mutation can be embedded within Arrowized FRP without breaking the laws: haskell.cs.yale.edu/wp-content/uploads/2015/10/… (btw most FRP libraries use Monads or even Applicatives, so it's not correct that Arrows are required).

[srph]

I'd like to add the rise of usage of "Reactive Extensions" (FRP Libraries; however, not FP) which was originally written for C# and then ported to Java (RxJava) and JavaScript (RxJS) and various languages. Check out reactivex.ioAt the point, Angular 2 makes extensive use of RxJS.

[Funk]

Steven Pemberton wrote 2 great posts on F# and WPF, his Thoughts on WPF development with F# towards the end of the second post adds to this discussion. 2 other examples that also intrigued me were the use of a functional controller in event driven MVVM and the use of discriminated unions and recursion for constructing a simple interface in the WPF controls demo by Flying Frog Consultancy.

[Luaan]

@BlueRaja-DannyPflughoeft Delphi and FoxPro came pretty close, and there's been quite a few declarative approaches to web programming (HTML and CSS are declarative by nature, some server and client frameworks fit well into that, some just drop back to the imperative style). The approach seems to go in and out of favour periodically with what people consider cool at the moment :)

[mac10688]

Sodium has been deprecated in favor of reactive banana according to Sodium's github readme

[Russia Must Remove Putin]

I have corrected luqui's link. May clean up some of these comments later. Probably best if someone edits relevant links into the post and flags the comments for obsolescence.

[icc97]

Here's the original FRP thesis behind Elm. But also since May 2016 Elm isn't a FRP language anymore.