I am quite aware of that *now*. Unfortunately, I wasn’t too well versed in the distinction when I originally wrote this article. I’ve considered revising it, but the changes would be fairly extensive, and given the fact that it’s a minor semantic point, I thought it best to leave things as they are.

There is also the fact that most people aren’t going to make the distinction and so would be confused by the proliferation of terminology. Generally, when someone says “Hindley-Milner”, they actually mean the type inference algorithm. Should they use the term “Damas-Milner” instead? Absolutely. Is it worth quibbling? Probably not.

This is an old argument but here it is anyway.

The problem with HM and OO is that this typing system does not have a property called principal typing. When a typing system has this property, and it is decidable, one can give the PT for the piece of code and any other typing for this piece can be obtained from this one. This allows you to have smart recompilation in your system. The lack of PT property has nothing to do with functional programming itself, but with the typing system used with the most popular ones.

There is a work going on with ML using intersection types instead of HM type system. Polymorphism by intersection is a promissing field, it list the multiple types instead of quantifying over it, as is done for HM.

Note that HM has principal TYPE property but no principal TYPING. The lack of modulatiry in the Dama/Milner algorithm can be notice that for “let N in M” program, one has to give a type for N and then for M. In a compositional type inference one can give type for N and M in parallel and check whether they can be related.

Good point; I hadn’t considered dependent types. With that said, I tend to consider dependent types to be flirting a little too closely with a full-blown meta-language. In fact, type systems with dependent types have a tendency toward intractability. That doesn’t make them any less valid, but it at least gives a better explanation for why I didn’t even consider them in my example.

Regarding inference, I’m pretty sure that it would be possible to infer the appropriate dependent type in examples as trivial as the one I gave. The trick would be to imbue the CT-If* rules with awareness of Boolean dependent types (required anyway to make the system work). However, in general, constraint-based inference for dependent types would certainly be undecidable. Shame…

Type systems are constraint logic programming, exactly. And as Daniel says, for every type system there are true things it can’t prove (see Godel). But when we say that HM always finds one principle type we don’t mean it will necessarily find a primitive type. In Haskell for instance

id x = x — A function that returns the value passed in unchanged

Gets inferred as
id :: forall t. t -> t

Meaning that the id function can take a value of any type and will return a value of that type.

Similarly
singletonList x = [x] — a function that boxes a single value into a list

Haskell infers
singletonList :: forall t. t -> [t]

Meaning if you pass in a value of any type ‘t’ the function gives back a value of type List of ‘t’.

Finally, a more complicated example using Haskell type classes

f x y z = x >>= y >>= z
f :: forall a, a1, b . (Monad m) => m a -> (a -> m a1) -> (a1 -> m b) -> m b

Which says that x must have a type “m a” where m is a special type constructor called a monad and “a” is some arbitrary type, y must have type “a -> m a1″ where a1 is some other arbitrary type, and z has type “a1 -> m b” where b is some arbitrary type. It will then return a value of type “m b”.

Hopefully this shows that principle types can be pretty sophisticated.

@Daniel,

Programs like what you wrote in Clojure above can be typed using dependent typing. However, afaik, there’s no way to infer dependent types.

You can get surprisingly far with simple let-polymorphism. Saying that HM is inferring *one* type implies that only a single nominal type will suffice, when really it is far more robust than that. If you extend the algorithm to encompass intersect and union types, you get even more power. Things aren’t quite as bleak as you think.

However, generally speaking you are correct. In any Turing Complete language, there will exist the possibility of code which is perfectly valid at runtime but not accepted by any type system, inference or no inference. Consider the following Clojure tidbit:

(defn do-stuff [c x]
  (if c
    (:foo x)
    (:bar x)))

(do-stuff true (struct (create-struct :foo) 123))

Even using every trick in the type systems book (structural types, intersect types, etc), there is no way to successfully type this snippet: the struct we are passing does not define a :bar property, meaning that it is *possible* that evaluation may fail. Of course, at runtime, things work out just fine since the (:bar x) form is in a non-evaluated branch. The type system doesn’t know that though, and there is no way for it to reliably find out. Dynamic languages are permanently safe in this regard.

Yup, brackets got smoked.

@Daniel

Yes of course polymorphism screws things too. Simplest example is that of an interface — by definition there’s no code to infer from, therefore no types.

Still more support even at the IDE level in Java (or similar language) would be useful. Sure if you know nothing about the types (or data), fine, but when you do, how nice would it be for the IDE to tell you?

There’s still plenty of code that calls non-polymorphic other code where this inference could help.

Of course this could also help at the runtime-VM or JIT layer, and in fact they already do simple things like that for e.g. removing array-out-of-bounds or null-pointer checks when it’s clear that those errors are impossible. Still I wonder if it could be made smarter through more inter-functional logic like this.