Effect systems: beyond flatmap

Scala Meetup Brabant + Amsterdam @Ordina

For our american guests: the cathedral from 1254 that still shows a space where a tornado tore down its middle“schrickelik tempeest” 1672

Of course we all come for Josh. But this may be of interest to you.

Oderskys troonrede at Scala Days Amsterdam

Hoera! Hoera! Hoera!

Troonrede: long live Odersky

At scala days Odersky states where Scala is going. At troonrede in NL the King does the same the coming financial year.

I’ll give a bit of background to one of the areas of exploration that he mentioned: effect systems

1/3

Why are side effects important?

How we’re used to dealing with side effects in Scala

Great for side effects but not always reactive streamable

Slick 3.0 design choice

• Db manipulation is all about side effects

• So how do you use FP to separate CPU intensive user code from IO intensive Slick code?

• Using flatmappable ‘db actions’

g

B

?

h

A

?

f

BA

def g: A => Unit

def f: A => B

def h: Unit => B

Side effects from an FP perspective

DBIO[A] (non streaming)

From: Hello Slick 3.0 example project

A DBIO[R] is a monad

So

• If you want to be fully reactive in dealing with f.i. persistence and use your servers and cores fully and build snappy applications you need to deal with side effects in a purely functional way

• Making the building blocks flatmappable allows us to put them together in an FP way

• So the general way to deal with side effects in FP is using monads

Monads are, like, so 5 minutes ago

It’s all about effect systems for the cool kids

2/3

Monads can be a hassle

We’ll have a brief look at what’s involved with dealing with multiple monads.

A spiffy asynchronous api for asking our users for their todos

Using Future[Option[String]] Not that easy. And that’s just with two different monads and 3 service calls

Let’s make the combination flatmappable

But what about Future[IO[Choice[Mut[_]]]]

?

And how is Future[IO[Choice[Mut[_]]]]

different from Future[IO[Mut[Choice[_]]]]

?

Monads specify an order even when you don’t want that: they are not commutative

Interlude: type classes

There’s another concept that Odersky uses in his explorative alternative approachLet’s extract what’s Future specific: just two static functions

These traits are wrappers for the Future type : there are not instances of these types, they offer static functions

type class: like doing polymorphism at the class level

Sometimes called evidence or capability

Sometimes you don’t even need to call its functions. Then it’s evidence or capability

Remove the implicit arguments from the function signature using context bound.Advantage: function declaration looks cleaner. Downside:

So

• Monads quickly become unwieldy when you deal with multiple of them

• They are ordered even when you don’t want them to

• You can’t express interleave

3/3

Effect systems: a better way?

Based on Phd thesis by

Lukas RitzOderskys solution is a bit

different by now

g

B

?

h

A

?

f

BA

def g: A => Unit

def f: A => B

def h: Unit => B

Types and effects can be viewed as separate dimensions

“Types constrain the inside, effects constrain the world outside”

Let’s have a look at the call graph

Let’s have a look at the call graph

Let’s look at the call graph

Side effects are infectious; once you call IO you’re IO as well

You should be able to add different effects

fromUrl has side effect ‘blocking’ where ‘noBlock’ is required

‘blocking’ function contains B side effect in call graph en turns it into noB

noBnoB

BB

noB

B

blocking

noB

Future

noB

B + nonB = B‘blocking’ function turns B effect into nonB

Example effect domain: synchronicity

• Atomic effects: B, noB

• Future function requires noB expression

• handler blocking has B argument and is itself noB

Effect domains• Mutating state

• IO

• exceptions

• non determinism

• latency, blocking

• null values

• …

The effect system is generic

Per domain• Sub effect relation

• Atomic effects

• A way to add effects together (‘join’)

• Absence of effect

• Arbitrary effect

There’s one mainstream language that contains

an effect system

checked exceptions also propagate up the call chaincatch contains the exception; ‘handles’ it.

Just like the blocking function contains the B side effect

Usability

• Java checked exceptions were not popular due to the necessity to copy declarations

• But in the effect system any effect is the default (demo)

• Effect checking can be turned off or on by compiler setting

Effect system scalar plugin by Lukas Ritz

Code demo

The syntax Odersky is considering instead

An intersection type is used to combine effects. This is similar to Trait1 with Trait2 construct

So

• An effect system in Scala will deal with side effects in an FP way while

• being order free and

• composable

• It won’t be in the next Scala version…

Want to know more about advanced FP

like this in Scala?

We’ll be going through this book

together. Join our little Utrecht

workgroup.

• Lukas Ritz Phd thesis http://lrytz.flavors.me/#publications-talks

• Code of the compiler plugin https://github.com/lrytz/efftp

• Kiselyov et al Extensible Effects http://www.cs.indiana.edu/~sabry/papers/exteff.pdf

• Port of Extensible Effects to Scala https://github.com/suhailshergill/scalable-effects

• Alternative approach Crockett generalises Scalas Async to other effects https://github.com/pelotom/effectful

• Kotelnikov Type-Directed Language Extension for Effectful Computations http://lampwww.epfl.ch/~hmiller/scala2014/proceedings/p35-kotelnikov.pdf

Ad hoc polymorphism in OCaml http://www.lpw25.net/ml2014.pdf

Odersky on direction https://twitter.com/odersky/status/598402881075748864

semi lattice explanation http://tecomp.sourceforge.net/index.php?file=doc/papers/proof/lattice.txt

semi lattice in de scala compiler http://www.scala-lang.org/api/2.11.0/scala-compiler/index.html#scala.tools.nsc.backend.icode.analysis.SemiLattice

rytz en odersky lightweight polymorphic effects http://infoscience.epfl.ch/record/175240/files/ecoop_1.pdf

proefschrift rytz https://dl.dropboxusercontent.com/u/4881107/website/thesis-rytz.pdffeb 2014

example van checked exceptions.vergelijk meet en join exceptions met future, ...

verwijst naar extensible effects paper van Oleg Kyselyov http://lambda-the-ultimate.org/node/4786

Miles Sabin Scala union types via Curry-Howard http://milessabin.com/blog/2011/06/09/scala-union-types-curry-howard/