DDevelopment & Design

Typeclasses in Swift, Haskell and Scala

What is a typeclass?

Typeclass is a Haskell way of creating the type composition in the world without inheritance. It allows to define a desired behavior in a form of function signatures. The concrete implementation is provided separately for all the required types. In other words, it splits the familiar object-oriented encapsulation (data and functionality together) in two separate parts: data and functionality. At the same time typeclass defines a contract that we can build upon. It’s like defining the same function multiple times – each time the only thing that differs is the type in the signature – and making it possible to use this function in some other place without specifying which one of its variants should be used. The compiler guesses it for us.

Doesn’t it sound like Swift or Objective-C protocols? Well, it does. It’s no surprise, because they’re all fueled by same basic idea. This is the first and arguably the most important thing to know about typeclasses – although they do have a word class in their name, they are more similar to protocols. Actually, they are far enough from classes so they can independently coexist with them, orthogonal to each other.

Typeclasses, being protocol cousins, are used in similar fashion: to express a feature that spreads across multiple types. In Haskell there are typeclasses like Eq, expressing that things are equatable, or Ord, expressing that they are sortable, or Functor, expressing that they can be mapped over.

If you’ve seen WWDC 2015 session “Protocol-Oriented Programming in Swift”, you’re gonna feel at home (or run away screaming, depending on how you liked it). One thing to notice: while in a more strict functional language, namely Haskell, typeclass is a part of its type semantics, in Swift or Scala typeclass is more of a design pattern. We’re using their native type semantics to achieve similar effects.

Enough with introduction. Let’s define a typeclass so we can more easily grasp what’s going on.

Things that can be encoded in Ceasar cipher

Have you heard of Caesar cipher? It is a very basic cryptography method: we express anything as a string and than we shift each letter by a fixed number of places in the alphabet. So, for 3-letter Ceasar cipher we write D instead of A, E instead of B, F instead of C and so on.

Our typeclass is gonna describe the ability to be expressed in a Ceasar cipher form. It’s gonna be based on position of particular character in the ASCII table. For the sake of simplicity I’ll ignore the fact that in the ASCII table there are some special characters after the last letters of the alphabet. No one is actually sending messages to Roman legions anymore, so no one is gonna get surprised by some %$#.

Here is the Ceasarable typeclass defined in Haskell:

class Ceasarable c where 
    toCeasar :: c -> String

Just to mess with object-oriented minds, it uses keyword class to kick off its definition. Then it declares one function signature: toCeasar. The function takes one argument of any type and returns a string, presumably with the cipher shift applied. This is our desired behavior. It must be implemented (with the actual type instead of c) by the typeclass instances.

How does it gonna look like in Scala? We’re gonna use Scala’s type semantics. The most obvious way is to use trait:

trait Ceasarable[T] {
    def toCeasar(input: T): String
}

The translation is straightforward. Any type in Haskell becomes a generic parameter in Scala. The signature is the same.

In Swift the closest thing to traits/interfaces are protocols, so let’s search no further:

protocol Ceasarable { 
    typealias T static func toCeasar(input: T) -> String 
}

Apart from minor syntax differences, like associated type instead of generic parameter, it’s the same as in Scala. Not surprising, as those two languages share a lot of similarities (and I mean like, a lot). One thing to notice is the use of static method. Why is it static? Because we want to emulate the split between the data and behavior. If the method is not static, than it can use the instance data and there is (in our simple case) no need to pass input at all. An instance method declaration would make the typeclass a little more object-oriented, and there’s nothing wrong with that, but for now let’s stick to the original idea. We’re providing the implementation for a type, not for an instance.

When I grow up I wanna be a typeclass!

Once we’ve defined what we expect, it’d be nice to provide some actual implementations for chosen types. This way we’d be able to use the behavior. Let’s choose two simple types to work with: strings and integers. In Haskell, the implementation is provided by defining the concrete typeclass instance:

{-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-}
    
instance Ceasarable String where
    toCeasar x = [toEnum $ fromEnum c + 3 | c <- x]
    
instance Ceasarable Integer where
    toCeasar x = [toEnum $ fromEnum c + 3 | c <- show x]

Keyword instance means that the implementation is coming. For String, we map over characters, get their ASCII numbers with fromEnum, add three and than encode again with toEnum. For Integer we just express it as String using show and we do exactly the same.

In Scala things get a little weird, so feel free to skip over the details. The Ceasarable behavior is enclosed in the object and marked as implicit. This way it can be implicitly passed to the place we want to use it:

object Ceasarable {
    implicit object CeasarableInt extends Ceasarable[Int] {
        override def toCeasar(input: Int): String = {
            s"$input".map(_ + 3).map(_.toChar).mkString
        }
    }
   
    implicit object CeasarableString extends Ceasarable[String] {
        override def toCeasar(input: String): String = {
            input.map(_ + 3).map(_.toChar).mkString
        }
    }
}

The object scope and implicit passing are part of Scala peculiarities, no need to dive deeper in them. If you really want to, look here. What matters is that we’ve created separated objects with Ceasarable implementations for String and Int types and we enclosed them in static-like objects (object is as close as you can get to static in Scala). Those types know nothing about their ability to be expressed in Ceasar cipher.

Let’s try the same approach in Swift:

struct CeasarableInt : Ceasarable {
    typealias T = Int
    static func toCeasar(input: Int) -> String {
        return "(input)".unicodeScalars.reduce("") { 
            (acc, char) in
            return acc + String(UnicodeScalar(char.value + 3))
        }
    }
}

struct CeasarableString : Ceasarable {
    typealias T = String
    static func toCeasar(input: String) -> String {
        return input.unicodeScalars.reduce("") { 
            (acc, char) in
            return acc + String(UnicodeScalar(char.value + 3))
        }
    }
}

Looks valid. This way we’ve defined the ability to be encoded in Ceasar cipher for strings and integers in each language we consider.

Now we can work with Ceasarable objects just as with any other group of objects sharing common characteristics, i.e. type. We can declare that we expect it as function parameter, we can return it in a function result and so on. Let’s see the example usages. In Haskell:

encodeInCeasar :: (Ceasarable c) => c -> String
encodeInCeasar = toCeasar
    
encodeInCeasar 1234 -- "4567"
    
encodeInCeasar "ABCabc" -- "DEFdef"

We are using the typeclass just like we’d use the protocol – to define a contract without explicitly defining what object are gonna conform to this contract.

How about Scala?

def encodeInCeasar[T: Ceasarable](c: T) = {
    val encoded = implicitly[Ceasarable[T]].toCeasar(c)
    println(encoded)
}

encodeInCeasar(1234) // "4567"

    encodeInCeasar("ABCabc") // "DEFdef"

The sky, once again, gets a little bit cloudy. Instead of requiring the protocol confirmation, we’re explicitly asking for the proper implementation using implicitly. Implicitly needs to have the implementations passed inside the function, and the enclosing scope is passed via a mechanism called context bound. T: Ceasarable is a syntax for context bound. It might sound confusing, but it’s fine, actually. This way we can easily see that we’re using a typeclass. In Swift, however, we encounter a problem:

func encodeInCeasar<C : Ceasarable>(c: C.T) -> String {
    return C.toCeasar(c)
}

encodeInCeasar(c: 1234) // Compiler error: Cannot invoke 'encodeInCeasar' with an argument list of type '(Int)'

Swift compiler cannot infer the generic parameter. There is a struct that does exactly what we want: conforms to Ceasarable and defines Int as its associated type. However, it cannot be found automatically. Swift doesn’t have semantics for Scala-like context bound. However, we’ve got the second best thing… Wait! It’s actually the first best thing, only Swift is 2.0. Protocol extensions.

Swift typeclasses defined with protocol extensions

In Swift we can use the extension keyword to provide implementations for already existing types. The beauty of extension lays in its two properties: universality and ability to be constraint. By universality I mean that you can extend all the Swift types: protocols, classes, structs and enums. The ability to be constraint let us express what we want to extend in a great detail – greater than allowed by protocol confirmation or class inheritance alone.

Did I mention that if you’ve watched “Protocol-Oriented Programming in Swift” you’ll feel at home? Our better implementation of typeclasses starts with a slight change to the Ceasarable definition:

protocol Ceasarable {
        static func toCeasar(input: Self) -> String
}

Instead of requiring the associated type in protocol, we can add a Self requirement. This way we’re expressing that for whatever type we’re providing the typeclass implementation, it requires the value of that type as the parameter. It stays closer to the original Haskell definition, because the typeclass doesn’t need to be generic. It is just like a template for multiple function definitions that differ only by the type in signature. Self expresses exactly that. There is also another way of expressing the same idea: see this article on how to do it using Swift 1.2 (spoiler alert: <C: Ceasarable where C.T == C>), but for Swift 2.0 the most straightforward way is with Self. The actual implementations become easier to write and more readable:

extension Int : Ceasarable {
    static func toCeasar(input: Int) -> String {
        return "(input)".unicodeScalars.reduce("") { 
            (acc, char) in
            return acc + String(UnicodeScalar(char.value + 3))
        }
    }
}

extension String : Ceasarable {
    static func toCeasar(input: String) -> String {
        return input.unicodeScalars.reduce("") { 
            (acc, char) in
            return acc + String(UnicodeScalar(char.value + 3))
        }
    }
}

It looks like a straightforward protocol confirmation and it’s just what we need. Having that, the usage get simpler as well:

func encodeInCeasar<T : Ceasarable>(c: T) -> String {
    return T.toCeasar(c)
}

encodeInCeasar(1234) // "4567"

encodeInCeasar("ABCabc") // "DEFdef"

This is what we tried to achieve. At the same time we’re providing behavior separate from data (since it’s static method of T) and expressing the common functionality (since T must be Ceasarable). By using protocol extensions, we’ve enabled the second dimension, somewhat orthogonal to inheritance, in which we can compose our functionalities.

What are Swift typeclasses, then?

A typeclass in Swift is a pattern build using the protocols and extensions. It’s simple and there’s nothing new, really, as we’ve been already using those concepts extensively. As a side note, the process of learning functional programming is very often like that: concepts we used for a long time, but differently named, generalized and ready to build upon.

Typeclasses are a way of providing a behavior for the type separately from the type and at the same time defining a contract that the type conforms to. It might be used to add functionalities and build composition without inheritance.

— Previous article

The hidden benefit of writing short methods

Next article —

Clojure web development - state of the art

You May Also Like
DDevelopment & Design

Need to make a quick json fixes – JSONPath for rescue

From time to time I have a need to do some fixes in my json data. In a world of flat files I do this with grep/sed/awk tool chain. How to handle it for JSON? Searching for a solution I came across the JSONPath. It quite mature tool (from 2007) but I haven't hear about it so I decided to share my experience with others.

First of all you can try it without pain online: http://jsonpath.curiousconcept.com/. Full syntax is described at http://goessner.net/articles/JsonPath/



But also you can download python binding and run it from command line:
$ sudo apt-get install python-jsonpath-rw
$ sudo apt-get install python-setuptools
$ sudo easy_install -U jsonpath

After that you can use inside python or with simple cli wrapper:
#!/usr/bin/python
import sys, json, jsonpath

path = sys.argv[1]

result = jsonpath.jsonpath(json.load(sys.stdin), path)
print json.dumps(result, indent=2)

… you can use it in your shell e.g. for json:
{
"store": {
"book": [
      {
"category": "reference",
"author": "Nigel Rees",
"title": "Sayings of the Century",
"price": 8.95
      },
      {
"category": "fiction",
"author": "Evelyn Waugh",
"title": "Sword of Honour",
"price": 12.99
      },
      {
"category": "fiction",
"author": "Herman Melville",
"title": "Moby Dick",
"isbn": "0-553-21311-3",
"price": 8.99
      },
      {
"category": "fiction",
"author": "J. R. R. Tolkien",
"title": "The Lord of the Rings",
"isbn": "0-395-19395-8",
"price": 22.99
      }
    ],
"bicycle": {
"color": "red",
"price": 19.95
    }
  }
}

You can print only book nodes with price lower than 10 by:
$ jsonpath '$..book[?(@.price

Result:
[
  {
"category": "reference",
"price": 8.95,
"title": "Sayings of the Century",
"author": "Nigel Rees"
  },
  {
"category": "fiction",
"price": 8.99,
"title": "Moby Dick",
"isbn": "0-553-21311-3",
"author": "Herman Melville"
  }
]

Have a nice JSON hacking!From time to time I have a need to do some fixes in my json data. In a world of flat files I do this with grep/sed/awk tool chain. How to handle it for JSON? Searching for a solution I came across the JSONPath. It quite mature tool (from 2007) but I haven't hear about it so I decided to share my experience with others.
DDevelopment & Design

How to use mocks in controller tests

Even since I started to write tests for my Grails application I couldn't find many articles on using mocks. Everyone is talking about tests and TDD but if you search for it there isn't many articles.

Today I want to share with you a test with mocks for a simple and complete scenario. I have a simple application that can fetch Twitter tweets and present it to user. I use REST service and I use GET to fetch tweets by id like this: http://api.twitter.com/1/statuses/show/236024636775735296.json. You can copy and paste it into your browser to see a result.

My application uses Grails 2.1 with spock-0.6 for tests. I have TwitterReaderService that fetches tweets by id, then I parse a response into my Tweet class.


class TwitterReaderService {
    Tweet readTweet(String id) throws TwitterError {
        try {
            String jsonBody = callTwitter(id)
            Tweet parsedTweet = parseBody(jsonBody)
            return parsedTweet
        } catch (Throwable t) {
            throw new TwitterError(t)
        }
    }

    private String callTwitter(String id) {
        // TODO: implementation
    }

    private Tweet parseBody(String jsonBody) {
        // TODO: implementation
    }
}

class Tweet {
    String id
    String userId
    String username
    String text
    Date createdAt
}

class TwitterError extends RuntimeException {}

TwitterController plays main part here. Users call show action along with id of a tweet. This action is my subject under test. I've implemented some basic functionality. It's easier to focus on it while writing tests.


class TwitterController {
    def twitterReaderService

    def index() {
    }

    def show() {
        Tweet tweet = twitterReaderService.readTweet(params.id)
        if (tweet == null) {
            flash.message = 'Tweet not found'
            redirect(action: 'index')
            return
        }

        [tweet: tweet]
    }
}

Let's start writing a test from scratch. Most important thing here is that I use mock for my TwitterReaderService. I do not construct new TwitterReaderService(), because in this test I test only TwitterController. I am not interested in injected service. I know how this service is supposed to work and I am not interested in internals. So before every test I inject a twitterReaderServiceMock into controller:


import grails.test.mixin.TestFor
import spock.lang.Specification

@TestFor(TwitterController)
class TwitterControllerSpec extends Specification {
    TwitterReaderService twitterReaderServiceMock = Mock(TwitterReaderService)

    def setup() {
        controller.twitterReaderService = twitterReaderServiceMock
    }
}

Now it's time to think what scenarios I need to test. This line from TwitterReaderService is the most important:


Tweet readTweet(String id) throws TwitterError

You must think of this method like a black box right now. You know nothing of internals from controller's point of view. You're only interested what can be returned for you:

  • a TwitterError can be thrown
  • null can be returned
  • Tweet instance can be returned

This list is your test blueprint. Now answer a simple question for each element: "What do I want my controller to do in this situation?" and you have plan test:

  • show action should redirect to index if TwitterError is thrown and inform about error
  • show action should redirect to index and inform if tweet is not found
  • show action should show found tweet

That was easy and straightforward! And now is the best part: we use twitterReaderServiceMock to mock each of these three scenarios!

In Spock there is a good documentation about interaction with mocks. You declare what methods are called, how many times, what parameters are given and what should be returned. Remember a black box? Mock is your black box with detailed instruction, e.g.: I expect you that if receive exactly one call to readTweet with parameter '1' then you should throw me a TwitterError. Rephrase this sentence out loud and look at this:


1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }

This is a valid interaction definition on mock! It's that easy! Here is a complete test that fails for now:


import grails.test.mixin.TestFor
import spock.lang.Specification

@TestFor(TwitterController)
class TwitterControllerSpec extends Specification {
    TwitterReaderService twitterReaderServiceMock = Mock(TwitterReaderService)

    def setup() {
        controller.twitterReaderService = twitterReaderServiceMock
    }

    def "show should redirect to index if TwitterError is thrown"() {
        given:
            controller.params.id = '1'
        when:
            controller.show()
        then:
            1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }
            0 * _._
            flash.message == 'There was an error on fetching your tweet'
            response.redirectUrl == '/twitter/index'
    }
}

| Failure:  show should redirect to index if TwitterError is thrown(pl.refaktor.twitter.TwitterControllerSpec)
|  pl.refaktor.twitter.TwitterError
 at pl.refaktor.twitter.TwitterControllerSpec.show should redirect to index if TwitterError is thrown_closure1(TwitterControllerSpec.groovy:29)

You may notice 0 * _._ notation. It says: I don't want any other mocks or any other methods called. Fail this test if something is called! It's a good practice to ensure that there are no more interactions than you want.

Ok, now I need to implement controller logic to handle TwitterError.


class TwitterController {

    def twitterReaderService

    def index() {
    }

    def show() {
        Tweet tweet

        try {
            tweet = twitterReaderService.readTweet(params.id)
        } catch (TwitterError e) {
            log.error(e)
            flash.message = 'There was an error on fetching your tweet'
            redirect(action: 'index')
            return
        }

        [tweet: tweet]
    }
}

My tests passes! We have two scenarios left. Rule stays the same: TwitterReaderService returns something and we test against it. So this line is the heart of each test, change only returned values after >>:


1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }

Here is a complete test for three scenarios and controller that passes it.


import grails.test.mixin.TestFor
import spock.lang.Specification

@TestFor(TwitterController)
class TwitterControllerSpec extends Specification {

    TwitterReaderService twitterReaderServiceMock = Mock(TwitterReaderService)

    def setup() {
        controller.twitterReaderService = twitterReaderServiceMock
    }

    def "show should redirect to index if TwitterError is thrown"() {
        given:
            controller.params.id = '1'
        when:
            controller.show()
        then:
            1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }
            0 * _._
            flash.message == 'There was an error on fetching your tweet'
            response.redirectUrl == '/twitter/index'
    }

    def "show should inform about not found tweet"() {
        given:
            controller.params.id = '1'
        when:
            controller.show()
        then:
            1 * twitterReaderServiceMock.readTweet('1') >> null
            0 * _._
            flash.message == 'Tweet not found'
            response.redirectUrl == '/twitter/index'
    }


    def "show should show found tweet"() {
        given:
            controller.params.id = '1'
        when:
            controller.show()
        then:
            1 * twitterReaderServiceMock.readTweet('1') >> new Tweet()
            0 * _._
            flash.message == null
            response.status == 200
    }
}

class TwitterController {

    def twitterReaderService

    def index() {
    }

    def show() {
        Tweet tweet

        try {
            tweet = twitterReaderService.readTweet(params.id)
        } catch (TwitterError e) {
            log.error(e)
            flash.message = 'There was an error on fetching your tweet'
            redirect(action: 'index')
            return
        }

        if (tweet == null) {
            flash.message = 'Tweet not found'
            redirect(action: 'index')
            return
        }

        [tweet: tweet]
    }
}

The most important thing here is that we've tested controller-service interaction without logic implementation in service! That's why mock technique is so useful. It decouples your dependencies and let you focus on exactly one subject under test. Happy testing!