This post aims to impart some of this natural feeling to those who are just breaking in. Hopefully, type class code will be easier to work with after reading.
A Crash Course in Implicit Resolution
Implicit scope in scala is insanely complex. Luckily, understanding the subtleties of the compiler algorithm are not a necessity. We only need to understand a few simple points:
- The implicit keyword
- Implicit values
- Implicit function parameters
The Implicit Keyword
This keyword tells the compiler that a function or value should be searchable in implicit scope. Implicit scope is the set of all implicit declarations in scope.
We'll now build up to using identifiers that are searchable in implicit scope.
Implicit Values
An implicit value is a value defined using the implicit keyword.
implicit val x = 7
Now, the value x is searchable in implicit scope. We'll make use of it later.
Implicit Function Parameters
An implicit function parameter, like an implicit value, is a parameter to a function that is marked with implicit.
def mkList(begin: Int)(implicit end: Int): List[Int] = {
(begin to end).toList
}
assert(List(1,2,3,4,5,6,7) == mkList(1)(7))
An implicit parameter works just like a parameter without the implicit declaration. So, what's the point?
Implicit parameters do not need to be explicitly written; if a value of the correct type is found in implicit scope, the compiler will automatically input that value for the developer to the function. The following is valid:
implicit val x = 7
def mkList(begin: Int)(implicit end: Int): List[Int] = {
(begin to end).toList
}
assert(List(1,2,3,4,5,6,7) == mkList(1))
assert(List(5,6,7) == mkList(5))
So What?
Implicit resolution is very handy for applying contexts to an application. A simple example is logging.
import scala.concurrent._
import ExecutionContext.Implicits.global
case class Logger(location: String){
def log(message: String) =
println(s"$message\t$location")
}
def monitoredOperation(a: String, b: Int)(implicit logger: Logger) = {
logger.log(a)
logger.log(b.toString)
logger.log(a + (2 * b))
}
val logA = Logger("logDir/a.log")
val logB = Logger("logDir/b.log")
def performA() = Future{
implicit val log = logA
monitoredOperation("A1", 5)
monitoredOperation("A2", 4)
monitoredOperation("A3", 3)
monitoredOperation("A4", 6)
}
def performB() = Future{
implicit val log = logB
monitoredOperation("B1", 4)
monitoredOperation("B2", 6)
monitoredOperation("B3", 5)
monitoredOperation("B4", 7)
}
implicit val logMain = Logger("logDir/.log")
for{
a <- performA()
b <- performB()
}{
monitoredOperation(".1", 8)
}There are three different paths for logging which are necessary at three separate points in the application. The implicit dependency monitoredOperation has on the logger lets the developer define a logging context at an appropriate scope and then code without giving thought to logging. This helps in two ways:
- The developer is free to code to the business case without being further burdened by logging
- Forces the developer to decouple code which logs to separate locations
The second help is illustrated by the following
implicit val logA = Logger("logDir/a.log")
implicit val logB = Logger("logDir/b.log")
monitoredOperation("", 0)//compile error: ambiguous implicit values
Bringing two values of the same type into implicit scope causes the compiler to fail on implicit resolution. The compiler cannot reason about which is the one you want.
Type Classes for Mortals
Type Classes are a technique for purely functional polymorphism. They are a powerful tool for using the scala compiler to help the developer group data types with similar use cases.
Building Type Classes
Say you need to extract lengths from GUIDs for validation however the GUIDs are presented in multiple formats.
- String
- List[Char]
- List[String]
For example:
val valid = 32
val id1 = "3F2504E0-4F89-41D3-9A0C-0305E82C3301"
val id2 = List('3', 'F', '2', '5', '0', '4', 'E', '0',
'4', 'F', '8', '9',
'4', '1', 'D', '3',
'9', 'A', '0', 'C',
'0', '3', '0', '5', 'E', '8', '2', 'C', '3', '3', '0', '1')
val id3 = List("3F2504E0", "4F89", "41D3", "9A0C", "0305E82C3301")
println(valid == id1.size)//false
println(valid == id2.size)//true
println(valid == id3.size)//false
In scala there is a built in size member for all three of these classes. The issue is, the three values represent the same GUID logically but, their size methods return very different results. Most of the time in OO, we would gain access to the classes, create a trait which validates them as GUIDs and have them each implement that trait. This is not possible since we are dealing with standard library classes. Type Classes provide a performant solution to this gap in functionality.
What is a Type Class?
A type class in scala is a trait with a parameter and at least one abstract method which contracts over the parameterized type. In our example it would look like:
trait Guid[T]{
def isGuid(item: T): Boolean
}This interface allows us to write a function for validating a GUID given an implementation of the Guid trait.
def guidIsValid[T](item: T, guid: Guid[T]): Boolean = {
guid.isGuid(item)
}Now, we just need to implement this trait for our three classes and use them as required. All together we have
val valid = 32
val id1 = "3F2504E0-4F89-41D3-9A0C-0305E82C3301"
val id2 = List('3', 'F', '2', '5', '0', '4', 'E', '0',
'4', 'F', '8', '9',
'4', '1', 'D', '3',
'9', 'A', '0', 'C',
'0', '3', '0', '5', 'E', '8', '2', 'C', '3', '3', '0', '1')
val id3 = List("3F2504E0", "4F89", "41D3", "9A0C", "0305E82C3301")
//use case
trait Guid[T]{
def isGuid(item: T): Boolean
}
def guidIsValid[T](item: T, guid: Guid[T]): Boolean = {
guid.isGuid(item)
}
val stringGuid = new Guid[String]{
override def isGuid(str: String): Boolean = {
val stripped = str.filter('-' != _)
valid == stripped.size
}
}
val lCharGuid = new Guid[List[Char]]{
override def isGuid(chars: List[Char]): Boolean = {
valid == chars.size
}
}
val lStringGuid = new Guid[List[String]]{
override def isGuid(strs: List[String]): Boolean = {
val size = strs.map(_.size).sum
valid == size
}
}
guidIsValid(id1, stringGuid)//true
guidIsValid(id2, lCharGuid)//true
guidIsValid(id3, lStringGuid)//trueHere, the compiler makes sure we have a valid implementation of our type class, Guid, for each call. This is nice but, the extra argument to the guidIsValid function makes the syntax more cumbersome than the OO version (OO version would have a validGuid method on String, List[Char] and List[String]). What we would like is for the last three lines to read
guidIsValid(id1)//true
guidIsValid(id2)//true
guidIsValid(id3)//true
Remember Implicits
Let's redefine our guidIsValid function so we can leverage the implicit functionality baked into the scala compiler to input our type class argument for our function
def guidIsValid[T](item: T)(implicit guid: Guid[T]): Boolean = {
guid.isGuid(item)
}
Now, if we redefine our type class implementations as implicits we have
trait Guid[T]{
def isGuid(item: T): Boolean
}
def guidIsValid[T](item: T)(implicit guid: Guid[T]): Boolean = {
guid.isGuid(item)
}
implicit val stringGuid = new Guid[String]{
override def isGuid(str: String): Boolean = {
val stripped = str.filter('-' != _)
valid == stripped.size
}
}
implicit val lCharGuid = new Guid[List[Char]]{
override def isGuid(chars: List[Char]): Boolean = {
valid == chars.size
}
}
implicit val lStringGuid = new Guid[List[String]]{
override def isGuid(strs: List[String]): Boolean = {
val size = strs.map(_.size).sum
valid == size
}
}
guidIsValid(id1)//true
guidIsValid(id2)//true
guidIsValid(id3)//true
Better compiler messages
To make it easier on implementors to reason about compile errors, type class library designers should always use the implicit not found annotation on their type classes.
@annotation.implicitNotFound("${T} has no implicit Guid instance defined in scope.")
trait Guid[T]{
def isGuid(item: T): Boolean
}
Working With Type Classes
We finally get to the main point of the tweet we referenced at the very beginning of this post:
how hard this code is ... to work with
First let's pick out just the type class and a single implementation from our code.
val valid = 32
trait Guid[T]{
def isGuid(item: T): Boolean
}
implicit val stringGuid = new Guid[String]{
override def isGuid(str: String): Boolean = {
val stripped = str.filter('-' != _)
valid == stripped.size
}
}
val id1 = "3F2504E0-4F89-41D3-9A0C-0305E82C3301"
This is the most basic kind of type class; its just a type class. The library has no functionality or guidance about how to use it. Most library designers add in a lot of extra implementation to the companion object for the type class. The companion object typically holds
- convenience functions for performing operations functionally
- something called Ops which wraps values in a context for the type class
- an implicit def into the Ops class for quickly performing operations with OO-style
trait Guid[T]{
def isGuid(item: T): Boolean
}
object Guid{
def apply[T](item: T)(implicit guid: Guid[T]): Boolean = {
guid.isGuid(item)
}
class GuidOps[T](item: T, guid: Guid[T]){
def isGuid(): Boolean = guid.isGuid(item)
}
implicit def lift[T](item: T)(implicit guid: Guid[T]): GuidOps[T] = {
new GuidOps[T](item, guid)
}
}With this definition in the library, the developer can choose which style to use
import Guid._
implicit val stringGuid = new Guid[String]{
override def isGuid(str: String): Boolean = {
val stripped = str.filter('-' != _)
valid == stripped.size
}
}
val id1 = "3F2504E0-4F89-41D3-9A0C-0305E82C3301"
Guid(id1)//functional
id1.isGuid()//object oriented
Type classes are simply the FP version of the decorator pattern from OO (This is made clear by the implicit def from T to GuidOps[T]; a direct mapping from the type class for some T to a decorator for T). They take a class and apply new uses to a single instance of that class without affecting other instances of that class. Together with implicits, they seem to augment a class directly (js prototype style) but, this appearance is simply an illusion created by the compiler as it decorates functions and objects for the developer.