What makes Haskell's type system more "powerful" than other languages' type systems?

Question

Reading Disadvantages of Scala type system versus Haskell?, I have to ask: what is it, specifically, that makes Haskell's type system more powerful than other languages' type systems (C, C++, Java). Apparently, even Scala can't perform some of the same powers as Haskell's type system. What is it, specifically, that makes Haskell's type system (Hindley–Milner type inference) so powerful? Can you give an example?

Answer 1

One thing I really like and miss in other languages is the support of typclasses, which are an elegant solution for many problems (including for instance polyvariadic functions).

Using typeclasses, it's extremely easy to define very abstract functions, which are still completely type-safe - like for instance this Fibonacci-function:

fibs :: Num a => [a]
fibs@(_:xs) = 0:1:zipWith (+) fibs xs

For instance:

map (`div` 2) fibs        -- integral context
(fibs !! 10) + 1.234      -- rational context
map (:+ 1.0) fibs         -- Complex  context

You may even define your own numeric type for this.

Answer 2

What is it, specifically, that makes Haskell's type system

It has been engineered for the past decade to be both flexible -- as a logic for property verification -- and powerful.

Haskell's type system has been developed over the years to encourage a relatively flexible, expressive static checking discipline, with several groups of researchers identifying type system techniques that enable powerful new classes of compile-time verification. Scala's is relatively undeveloped in that area.

That is, Haskell/GHC provides a logic that is both powerful and designed to encourage type level programming. Something fairly unique in the world of functional programming.

Some papers that give a flavor of the direction the engineering effort on Haskell's type system has taken:

• Fun with type functions
• Associated types with class
• Fun with functional dependencies

Answer 3

Hindley-Milner is not a type system, but a type inference algorithm. Haskell's type system, back in the day, used to be able to be fully inferred using HM, but that ship has long sailed for modern Haskell with extensions. (ML remains capable of being fully inferred).

Arguably, the ability to mainly or entirely infer all types yields power in terms of expressiveness.

But that's largely not what I think the question is really about.

The papers that dons linked point to the other aspect -- that the extensions to Haskell's type system make it turing complete (and that modern type families make that turing complete language much more closely resemble value-level programming). Another nice paper on this topic is McBride's Faking It: Simulating Dependent Types in Haskell.

The paper in the other thread on Scala: "Type Classes as Objects and Implicits" goes into why you can in fact do most of this in Scala as well, although with a bit more explicitness. I tend to feel, but this is more a gut sense than from real Scala experience, that its more ad-hoc and explicit approach (what the C++ discussion called "nominal") is ultimately a bit messier.

Answer 4

Haskell language allows you to write safer code without giving up with functionalities. Most languages nowadays trade features for safety: the Haskell language is there to show that's possible to have both.

We can live without null pointers, explicit castings, loose typing and still have a perfectly expressive language, able to produce efficient final code.

More, the Haskell type system, along with its lazy-by-default and purity approach to coding gives you a boost in complicate but important matters like parallelism and concurrency.

Just my two cents.

Answer 5

Let's go with a very simple example: Haskell's Maybe.

data Maybe a = Nothing | Just a

In C++:

template <T>
struct Maybe {
    bool isJust;
    T value;  // IMPORTANT: must ignore when !isJust
};

Let's consider these two function signatures, in Haskell:

sumJusts :: Num a => [Maybe a] -> a

and C++:

template <T> T sumJusts(vector<maybe<T> >);

Differences:

• In C++ there are more possible mistakes to make. The compiler doesn't check the usage rule of Maybe.
• The C++ type of sumJusts does not specify that it requires + and cast from 0. The error messages that show up when things do not work are cryptic and odd. In Haskell the compiler will just complain that the type is not an instance of Num, very straightforward..

In short: Haskell has ADTs, type-classes, and a very friendly syntax and good support for generics, which in C++ people try to avoid because of all their cryptickynessishisms.