Typeclasses in Swift, Haskell and Scala

byKrzysztof Siejkowski
September 14, 2015
7 minute read

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: 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: ), 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(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.

Krzysztof Siejkowski

— Previous article

The hidden benefit of writing short methods

Next article —

Clojure web development - state of the art

Spock basics

byRafał Nowak
September 7, 2013

Spock (homepage) is like its authors say 'testing and specification framework'. Spock combines very elegant and natural syntax with the powerful capabilities. And what is most important it is easy to use.

One note at the very beginning: I assume that you are already familiar with principles of Test Driven Development and you know how to use testing framework like for example JUnit.

So how can I start?

Writing spock specifications is very easy. We need basic configuration of Spock and Groovy dependencies (if you are using mavenized project with Eclipse look to my previous post: Spock, Java and Maven). Once we have everything set up and running smooth we can write our first specs (spec or specification is equivalent for test class in other frameworks like JUnit of TestNG).

What is great with Spock is fact that we can use it to test both Groovy projects and pure Java projects or even mixed projects.

Let's go!

Every spec class must inherit from spock.lang.Specification class. Only then test runner will recognize it as test class and start tests. We will write few specs for this simple class: User class and few tests not connected with this particular class.

We start with defining our class:

import spock.lang.*

class UserSpec extends Specification {

}

Now we can proceed to defining test fixtures and test methods.

All activites we want to perform before each test method, are to be put in def setup() {...} method and everything we want to be run after each test should be put in def cleanup() {...} method (they are equivalents for JUnit methods with @Before and @After annotations).

It can look like this:

class UserSpec extends Specification {
    User user
    Document document

    def setup() {
        user = new User()
        document = DocumentTestFactory.createDocumentWithTitle("doc1")
    }

    def cleanup() {

    }
}

Of course we can use field initialization for instantiating test objects:

class UserSpec extends Specification {
    User user = new User()
    Document document = DocumentTestFactory.createDocumentWithTitle("doc1")

    def setup() {

    }

    def cleanup() {

    }
}

What is more readable or preferred? It is just a matter of taste because according to Spock docs behaviour is the same in these two cases.

It is worth mentioning that JUnit @BeforeClass/@AfterClass are also present in Spock as def setupSpec() {...} and def cleanupSpec() {...}. They will be runned before first test and after last test method.

First tests

In Spock every method in specification class, expect setup/cleanup, is treated by runner as a test method (unless you annotate it with @Ignore).

Very interesting feature of Spock and Groovy is ability to name methods with full sentences just like regular strings:

class UserSpec extends Specification {
    // ...

    def "should assign coment to user"() {
        // ...
    }
}

With such naming convention we can write real specification and include details about specified behaviour in method name, what is very convenient when reading test reports and analyzing errors.

Test method (also called feature method) is logically divided into few blocks, each with its own purpose. Blocks are defined like labels in Java (but they are transformed with Groovy AST transform features) and some of them must be put in code in specific order.

Most basic and common schema for Spock test is:

class UserSpec extends Specification {
    // ...

    def "should assign coment to user"() {
        given:
            // do initialization of test objects
        when:
            // perform actions to be tested
        then:
            // collect and analyze results
    }
}

But there are more blocks like:

setup
expect
where
cleanup

In next section I am going to describe each block shortly with little examples.

given block

This block is used to setup test objects and their state. It has to be first block in test and cannot be repeated. Below is little example how can it be used:

class UserSpec extends Specification {
    // ...

    def "should add project to user and mark user as project's owner"() {
        given:
            User user = new User()
            Project project = ProjectTestFactory.createProjectWithName("simple project")
        // ...
    }
}

In this code given block contains initialization of test objects and nothing more. We create simple user without any specified attributes and project with given name. In case when some of these objects could be reused in more feature methods, it could be worth putting initialization in setup method.

when and then blocks

When block contains action we want to test (Spock documentation calls it 'stimulus'). This block always occurs in pair with then block, where we are verifying response for satisfying certain conditions. Assume we have this simple test case:

class UserSpec extends Specification {
    // ...

    def "should assign user to comment when adding comment to user"() {
        given:
            User user = new User()
            Comment comment = new Comment()
        when:
            user.addComment(comment)
        then:
            comment.getUserWhoCreatedComment().equals(user)
    }

    // ...
}

In when block there is a call of tested method and nothing more. After we are sure our action was performed, we can check for desired conditions in then block.

Then block is very well structured and its every line is treated by Spock as boolean statement. That means, Spock expects that we write instructions containing comparisons and expressions returning true or false, so we can create then block with such statements:

user.getName() == "John"
user.getAge() == 40
!user.isEnabled()

Each of lines will be treated as single assertion and will be evaluated by Spock.

Sometimes we expect that our method throws an exception under given circumstances. We can write test for it with use of thrown method:

class CommentSpec extends Specification {
    def "should throw exception when adding null document to comment"() {
        given:
            Comment comment = new Comment()
        when:
            comment.setCommentedDocument(null)
        then:
            thrown(RuntimeException)
    }
}

In this test we want to make sure that passing incorrect parameters is correctly handled by tested method and that method throws an exception in response. In case you want to be certain that method does not throw particular exception, simply use notThrown method.

expect block

Expect block is primarily used when we do not want to separate when and then blocks because it is unnatural. It is especially useful for simple test (and according to TDD rules all test should be simple and short) with only one condition to check, like in this example (it is simple but should show the idea):

def "should create user with given name"() {
    given:
        User user = UserTestFactory.createUser("john doe")
    expect:
        user.getName() == "john doe"
}

More blocks!

That were very simple tests with standard Spock test layout and canonical divide into given/when/then parts. But Spock offers more possibilities in writing tests and provides more blocks.

setup/cleanup blocks

These two blocks have the very same functionality as the def setup and def cleanup methods in specification. They allow to perform some actions before test and after test. But unlike these methods (which are shared between all tests) blocks work only in methods they are defined in.

where - easy way to create readable parameterized tests

Very often when we create unit tests there is a need to "feed" them with sample data to test various cases and border values. With Spock this task is very easy and straighforward. To provide test data to feature method, we need to use where block. Let's take a look at little the piece of code:

def "should successfully validate emails with valid syntax"() {
    expect:
        emailValidator.validate(email) == true
    where:
        email }

In this example, Spock creates variable called email which is used when calling method being tested. Internally feature method is called once, but framework iterates over given values and calls expect/when block as many times as there are values (however, if we use @Unroll annotation Spock can create separate run for each of given values, more about it in one of next examples).

Now, lets assume that we want our feature method to test both successful and failure validations. To achieve that goal we can create few parameterized variables for both input parameter and expected result. Here is a little example:

def "should perform validation of email addresses"() {
    expect:
        emailValidator.validate(email) == result
    where:
        email         result }

Well, it looks nice, but Spock can do much better. It offers tabular format of defining parameters for test what is much more readable and natural. Lets take a look:

def "should perform validation of email addresses"() {
    expect:
        emailValidator.validate(email) == result
    where:
        email           | result
        "WTF"           | false
        "@domain"       | false
        "foo@bar.com"   | true
        "a@test"        | false
}

In this code, each column of our "table" is treated as a separate variable and rows are values for subsequent test iterations.

Another useful feature of Spock during parameterizing test is its ability to "unroll" each parameterized test. Feature method from previous example could be defined as (the body stays the same, so I do not repeat it):

@Unroll("should validate email #email")
def "should perform validation of email addresses"() {
    // ...
}

With that annotation, Spock generate few methods each with its own name and run them separately. We can use symbols from where blocks in @Unroll argument by preceding it with '#' sign what is a signal to Spock to use it in generated method name.

What next?

Well, that was just quick and short journey through Spock and its capabilities. However, with that basic tutorial you are ready to write many unit tests. In one of my future posts I am going to describe more features of Spock focusing especially on its mocking abilities.

DDevelopment & Design

Visualizing GIS data in JavaFX 2.0 beta using GeoTools

byRafal Rusin
June 13, 2011

Geographic data mostly comprises of polygon coordinates sets along with attributes, like country or city name, etc. This is quite easy to visualize in JavaFX, which supports rendering for SVG paths. In the article, I show how to read such GIS data from...Geographic data mostly comprises of polygon coordinates sets along with attributes, like country or city name, etc. This is quite easy to visualize in JavaFX, which supports rendering for SVG paths. In the article, I show how to read such GIS data from...