Haskell: Initial reactions


I had never actually used any of the modern functional programming languages until a couple of weeks ago. However, I’ve worked quite a lot with the functional features of more multi-paradigm languages: python, R, ruby, javascript, etc. so I didn’t expect to be caught off guard by Haskell.

I decided to learn Haskell because I wanted to extend the wonderful Pandoc, which is written in Haskell. This turned out to be a bit more ambitious than I expected.


I was almost entirely unprepared for the way Haskell thinks about types. The more functional languages I’ve used have tended to have somewhat weaker type concepts, from the duck-typing of python to the not-really-a-type S3 classes in R.

The types are strong with this one

In contrast, Haskell is strongly typed, and I had not appreciated just how strongly typed it is. To an uninitiated Haskell outsider, I would not have expected types to be a big part of understanding the Pandoc source code. However, in Haskell, types are “merely” data containers, meaning that any and all containers/structs are new types. This happens because there is no real concept of “method” in the object-oriented sense.

Making it worse was the fact that I really did not understand Haskell types. Haskell has completely different concepts for types constructors and data constructors. Types do not actually exist as anything you can refer to in Haskell.

f :: FromType -> ToType
data FromType = FromTypeConstructor Value

Here, you can create an object of type FromType with FromTypeConstructor value if value has type Value. However, FromType itself has no value.

When names collide

This gets particularly complicated since types and constructors have completely separate namespaces! As an example, in Text.JSON, JSObject is both a type and a constructor, but the JSObject constructor does not create JSObject type objects. Instead, JSONObject must be used to construct objects of type JSObject, while the constructor JSObject creates objects of type JSValue.