This document summarizes Martin Odersky's talk on implicits in Scala. The key points are: 1. Implicits allow certain values or functions to be passed implicitly rather than explicitly as parameters. This can avoid tedious repetition when many parameters rarely change. 2. Implicits are commonly used to establish context, inject dependencies, implement type classes, and prove theorems by modeling types as theorems and programs as proofs. 3. Future changes to implicits in Scala 3 include allowing multiple implicit parameter lists, implicit by-name parameters, and implicit function types which avoid wrapping implicits in monads.

1. What to Leave Implicit
Martin Odersky
Curry On and PLDI
Barcelona, June 2017

2. Con-textual
what comes with the text,
but is not in the text

3. Context is all around us
• the current configuration
• the current scope
• the meaning of “<” on this type
• the user on behalf of which the
operation is performed
• the security level in effect
• …

4. • globals
rigid if immutable,
unsafe if mutable
• monkey patching
• dependency injection
at runtime (Spring, Guice)
or with macros (MacWire)
• cake pattern
close coupling + recursion
Traditional ways to express context

5. “Parameterize all the things”
The Functional Way

6. - no side effects
- type safe
- fine-grained control
Functional is Good

7. - sea of parameters
- most of which hardly ever change
- repetitive, boring, prone to mistakes
But sometimes it’s too much of a
good thing …

8. If passing a lot of parameters gets tedious,
leave some of them implicit.
A more direct approach

9. Implicits
Types
ObjectsFunctions
Essence of Scala
Synthesis
If there’s one feature
that makes Scala
“Scala”, I would pick
implicits.

10. • takes you through some common uses of implicits,
and some interesting new ones,
• goes through a set of language changes that will
make implicits even more powerful and safer to use.
This Talk
t

11. • If you do not give an argument to an implicit parameter,
one will be provided for you.
• Eligible are all implicit values that are visible at the
point of call.
• If there are more than one eligible candidate, the most
specific one is chosen.
• If there’s no unique most specific candidate, an
ambiguity error Is reported.
Ground Rules

12. • are a cousin of implicit parameters.
• If the type A of an expression does not match the
expected type B …
… the compiler tries to find an implicit conversion
method from A to B.
• Same rules as for implicit parameters apply.
Implicit Conversions

13. • … implicit conversions came first in Scala.
• Original motivation: Provide a way for a class to
implement new interfaces.
• Implicit conversions were at first adopted
enthusiastically, but nowadays are mostly discouraged.
• I will ignore them in the rest of this talk.
Historically …

14. Implicit parameters can
• prove theorems
• establish context
• set configurations
• inject dependencies
• model capabilities
• implement type classes
Implicit Parameters - Use Cases

15. Curry Howard isomorphism:
Types = Theorems
Programs = Proofs
C.f. Kennedy & Russo: “Generalized Type Constraints”, OOPSLA 2004
Prove Theorems

16. Establish Context
Example: conference management system.
Reviewers should only see (directly or indirectly) the
scores of papers where they have no conflict with an
author.

17. Establish Context
Example: conference management system.
Context is usually stable, can change at specific points.

18. Configuration &
Dependency Management
are special cases of context passing.
see also: Dick Wall: The parfait pattern

19. Implement Type Classes

20. Implement Type Classes

21. Some changes to implicits foreseen for Scala 3:
1. Stricter distinction between parameters and
conversions
2. Implicit by-name parameters
3. Multiple implicit parameter lists
4. Implicit function types
New Developments

22. Multiple Implicit Parameter Lists
Problem: Implicit parameters are currently a bit irregular
compared to normal parameters:
• there can be only one implicit parameter section
• and it must come last.
This leads to some awkward workarounds (c.f. Aux
pattern).
Related problem: It’s sometimes confusing when a
parameter is implicit or explicit.

23. Proposal:
• Allow multiple implicit parameter lists
• Implicit and explicit parameter lists can be mixed freely.
• Explicit application of an implicit parameter must be
marked with a new “magic” method, explicitly.
Multiple Implicit Parameter Lists

24. Implicit Function Types
Let’s look at the conference management system again

25. Can we do better?
Having to write
a couple of times does not look so bad.
But in dotc there are > 2600 occurrences of the parameter
Would it not be nice to get rid of them?

26. Towards a solution
Let’s massage the definition of viewRankings a bit:
What is its type?
So far: Viewers => List[Paper]
From now on: implicit Viewers => List[Paper]

27. Two Rules for Typing
1. Implicit functions get implicit arguments just like implicit
methods. Given:
f expands to f(a).
2. Implicit functions get created on demand. If the
expected type of b is implicit A => B, then
b expands to implicit (_: A) => b

28. Revised Example
Assume:
Then reformulate:

29. Efficiency
Implicit function result types can be optimized
Instead of creating a closure like this:
we can simply create a curried function like this:
This brings the cost of implicit functions down to simple
implicit parameters.

30. • The reader monad is a somewhat popular method to
pass context.
• Essentially, it wraps the implicit reading in a monad.
• One advantage: The reading is abstracted in a type.
• But I believe this is shooting sparrows with cannons.
• Monads are about sequencing, they have have nothing
to do with passing context.
The Reader Monad

31. • allow the same conciseness as the reader monad,
• don’t force you into monadic style with explicit
sequencing,
• are fully composable,
• are more than 7x faster than the reader monad.
Implicit Function Types

32. Neat way to define structure-building DSLs, like this:
Natively supported in Groovy and in Kotlin via “receiver
functions”.
An Encore: The Builder Pattern

33. Scala Implementation

34. A Formalization
Bidirectional typing rules:
Γ ⊢ t :▷ T (Synthesis)
Γ ⊢ t ◁: T (Checking)

35. SI Typing Rules: Functions

36. SI Typing Rules: Variables

37. SI Typing Rules: Let

38. SI Typing Rules: Everything

39. Translation to System F

40. • Implicit parameters in Haskell (Lewis et al, 2000)
• Modular implicits in OCaml (White, Bour, Yallop, 2015)
• Agda’s implicit instances (Devriese and Piessens, 2011)
- very similar to implicit function types.
• Implicit Calculus by (Olivera, Schrjvers, Wadler et al.,
2012, 2017)
- a bit further removed from Scala than SI.
- Foundations of Implicit Function Types (Odersky,
Biboudis, Liu, Blanvillain) EPFL Report 229203, 2017
References

41. Dotty: Dmitry Petrashko Nicolas Stucki
Guillaume Martres Felix Mulder
Ondrej Lhotak Aggelos Biboudis
Liu Fengyun Vera Salvis
Olivier Blanvillain Enno Runne
Sebastien Douraene … and many others
DOT: Nada Amin Tiark Rompf
Sandro Stucki Samuel Grütter
scalac at Adriaan Moors Seth Tisue
Lightbend: Jason Zaugg Stefan Zeiger
Lukas Rytz
Scala Heather Miller Julien Richard-Foy
Center: Jorge Cantero Olafur Geirsson
Guillaume Massé Martin Duheim
Travis Lee
Credits
Thank You