Asynchronous Functional Reactive Programming for GUIs

by Evan Czaplicki and Steven Chong

Presentation by Daniel Bugl

Overview

Introduction to FRP
Problems with FRP
Solution: Elm
Results of paper / Benchmark

FRP?

functional: pure functional programming paradigms

reactive: applied to time-varying values (signals)

i = 0
function increment () {
  return ++i
}

increment() // 1
increment() // 2

function increment (i) {
  return i + 1
}


increment(0) // 1
increment(1) // 2

impure:

pure:

functional reactive programming

Signals

time-varying values ("values that change over time")
e.g. user interaction, server requests and responses

Signals

most FRP languages:
- assume that signals change continuously
- → sample input signals as quickly as possible
- → continually recompute the program with the latest values for the signals
In practice, however:
- many signals change discretely and infrequently
- → constant sampling leads to unnecessary recomputation

Problems with FRP

Inefficiencies:
- Unnecessary Recomputation (resulting from continuous/pull-approach to signals)
- Global delays (resulting from keeping the global order of events)
  - e.g. waiting for server response before accepting user input again

Solution: Elm

what: a functional reactive programming (FRP) language
goals:
- simplify creation of responsive graphical user interfaces (GUIs)
- solve inefficiency problems with current FRP implementations
target: web applications (compiles to JavaScript)

Solution: Elm

content = flow down [ plainText "Welcome to Elm!"
                    , image 150 50 "flower.jpg"
                    , asText (reverse [1..9]) ]

main = container 180 100 middle content

flow : Direction -> [Element] -> Element

container : Int -> Int -> Position -> Element -> Element

Solution: Elm

Unnecessary Recomputation:
assume discrete events (signals only change when events occur)
→ push approach (global event dispatcher)

main = lift asText Mouse.position

Mouse.position : Signal (Int,Int)

lift : (a -> b) -> Signal a -> Signal b

asText : a -> Element

Solution: Elm

Global event dispatcher
- dispatches all events to all signal sources
- signal sources decide if value changed or not
- if not, return:

noChange v

Solution: Elm

Global delays:
allow programmer to specify when something should be executed regardless of the order of events
→ asynchronous execution (async construct)

(inputField, tags) = Input.text "Enter a tag"

getImage tags =
  lift (fittedImage 300 200)
       (syncGet (lift requestTag tags))

scene input pos img =
  flow down [ input, asText pos, img ]

main = lift3 scene inputField
                   Mouse.position
                   (async (getImage tags))

Results of paper

developed Elm
a practical, asynchronous FRP language
with focus on easy creation of responsive GUIs
allowed efficient execution of FRP programs
(push approach)
introduced Asynchronous FRP
(async construct)

→ Elm simplifies the complicated task of creating responsive and usable graphical user interfaces

Benchmark

Source: elm-lang.org/blog/blazing-fast-html

Questions?

Try out Elm!

elm-lang.org/try

Elm Type System

simple types:
- base types
- functions from simple types to simple types

signal types:
- "streams of values"
- not possible: signals of signals
  - would require saving full history of values

Asynchronous Functional Reactive Programming for GUIs

Overview

FRP?

Signals

Signals

Problems with FRP

Solution: Elm

Solution: Elm

Solution: Elm

Solution: Elm

Solution: Elm

Results of paper

Benchmark

Questions?

Try out Elm!

elm-lang.org/try

Elm Type System

Asynchronous Functional Reactive Programming for GUIs

More from omnidan