Date post: | 14-Apr-2017 |
Category: |
Technology |
Upload: | joost-de-vries |
View: | 63 times |
Download: | 1 times |
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
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
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
2/3
Monads can be a hassle
We’ll have a brief look at what’s involved with dealing with multiple monads.
Using Future[Option[String]] Not that easy. And that’s just with two different monads and 3 service calls
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
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 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
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
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/