Why I quite like Scala's type system

My colleague Gary pointed me at a blog post by Stephen Colebourne that is critical of Scala, along with a related Reddit thread, and asked me what I thought. Some points are fair enough, for example the Scala community has an elitist Functional Programming cadre who clustered around the Scalaz library who tend to be particularly obnoxious. I've already experienced the ire of one of their members, and from the private emails I've received I know I'm not the only one to have been the butt-end of his displeasure. As a generalisation they seem to have come from a Haskell background and it appears that they won't be satisfied until Scala turns into Haskell. There's an obvious solution to that which I'll refrain from pointing out... ;-)

The blog post linked to above recycles common criticisms of two Scala features without actually considering why they might have been provided in the first place. The features in question are Higher-Kinded Types (AKA Constructor Polymorphism) and Implicit Parameters. I'd expect a more substantial argument than "It's too complicated and hard" - that just seems lazy. Yes, it's complicated, generic programming nearly always is. For example, Java Generics are commonly accepted as being A Good Thing In General yet I can't see how any language feature that has a 297-page FAQ is anything other than complicated.

There are many, many blog posts, mailing list discussions and academic papers out there which discuss Scala's use of Higher-Kinded Types and Implicit Parameters. Two of the best academic papers (both PDFs) are:

While they are interesting and well worth a read they aren't exactly written in a way you'd use to describe the benefits of Scala to your mates in the pub. However, hidden away in the second paper is a little example that shows why the combination of Higher-Kinded Types and Implicit Parameters is so powerful, and is such an advance over Java.

Scala's Implicit Parameters are really just a house-trained version of C++ user-defined type conversion operators, nothing more. They are a way of allowing you to specify how one type of thing should be converted into another.

Higher-Kinded Types are a little more difficult to grasp. Java has types such as List which are 'kinded types', e.g. a List<Integer> is a 'kind of' list. However in Scala you can go beyond that and define types which are the equivalent of L<T> where both L and T are type parameters. Why is that useful? Well, because it allows you to write code that manipulates all sorts of list-like things irrespective of their actual types. Like Java Generics it's really of most use to the writers of libraries rather than day-to-day use, but in combination with Implicit Parameters it does allow things you just can't do in Java.

OK, on to the example. To show these two language features in action together, we'll use the Scala BitSet class which implements a set using bits in integers for compact storage:

scala> val b = BitSet(2,4,8)
b: scala.collection.immutable.BitSet = BitSet(2, 4, 8)

Straightforward so far. Now let's map that bitset by adding 1 to each element:

scala> b.map(v => v + 1)
res0: scala.collection.immutable.BitSet = BitSet(3, 5, 9)

OK, that's what we would expect - we get back a new BitSet. Now let's do something that would be impossible in Java's type system. Let's map over the bitset again, but this time the returned values will be something that can't be stored in bits. Let's map the bitset contents to String:

scala> b.map(v => "bit " + v)
res1: scala.collection.immutable.Set[java.lang.String] = Set(bit 2, bit 4, bit 8)

Now let's try mapping the contents to floating point numbers:

scala> b.map(v => v * 1.5)
res3: scala.collection.immutable.Set[Double] = Set(3.0, 6.0, 12.0)

So what we get back is not just a set of different values (and types) to the ones we started with, the container those types are stored in is different as well - BitSet becomes Set[Double]. That transformational magic is not a language-level feature, it's all done in at library level by making use of both the powerful (and yes, complex) type system and implicit parameters - for a full explanation, see the papers above. The important takeaway is that you get the appearance and behaviour you might expect of an untyped language such as Python (notice, the types of b and c are never declared) and yet Scala is actually strongly typed.

Here's the coup de grace. Let's write something that stores the return of the integer map operation in a variable, then let's assign the result of the floating point map operation to the same variable. I'm doing this in the interpreter's 'paste' mode so it's compiled all in on go:

scala> :paste
// Entering paste mode (ctrl-D to finish)

val b = BitSet(2,4,8)
var c = b.map(v => v + 1)
c = b.map(v => v * 1.5)
// Exiting paste mode, now interpreting.

<console>:10: error: type mismatch;
 found   : scala.collection.Set[Double]
 required: scala.collection.BitSet
       c = b.map(v => v * 1.5)

Note that's a compile time error, not a run-time one, and the parts involved are all library classes, not fundamental language features. How does it work? Well, the type of c is inferred by the compiler so it knows that c is a BitSet. It can also work out at compile-time that the return type of the second map operation will be Set[Double], and that's not type-compatible with BitSet, so you get a compile-time error. Yet there's not an explicit type declaration in sight. Python, eat your heart out ;-)

I don't just think this is cool because I'm some sort of strict-typing bigot, one of my teensy claims to fame is that my name is in the Perl AUTHORS file so feel I've earned my dynamically-typed Scout's badge. However, given a choice between strong and weak typing I'd prefer strong typing just because it helps protect me from my own stupidity. Obviously the example above is not the only possible use of these Scala language features, but I do think it's a good, simple illustration of how they can be used. And no, this kind of power isn't easy to wield. As the second paper listed above says:

Getting this design right was very hard, however. It took us about a year to go from a first sketch to the final implementation. In doing this work, we also encountered some dead ends.

However saying that Scala shouldn't provide support for powerful concepts just because they are hard to get your head around seems completely wrong-headed. The difficulty is in the concepts more than it is in the implementation. The blog post that prompted this points to the Fantom language as a superior alternative to Scala, yet the Why Fantom page contains the following:

Currently Fantom takes a limited approach to generics. There is no support for user defined generics yet. However, three built-in classes List, Map, and Func can be parameterized using a special syntax. For example a list of Ints in Fantom is declared as Int[] using the familiar array type syntax of Java and C#. This trade-off seems to hit the sweet spot where generics make sense without complicating the overall type system.

So pretending the need for Generics doesn't exist seems to be their solution. Boggle.

Stupid BT router...

I have the misfortune to own a BT Business 2Wire router, and bleaklow.com sits behind that. A while back it threw a fit and reconfigured itself and when I beat it into submission I didn't notice that it had also lost the port mappings for bleaklow.com. As a result I've been off-air for quite some time. Bloody BT...

Tags : ,
Categories : Web, Tech