And of cource, you can add the types explicitly anywhere to make finding errors easier.

The real problem, which I didn’t directly address in the article, is the fact that Hindley-Milner-style type inference removes the type error from its origin, sometimes quite far from the origin. As you say, we would immediately see the problem with my contrived example the moment we tried to use the function. However, who’s to say that we’ll be able to easily track down what’s going on? For example, suppose that we used the function in the following way:

fun contrived nil n = n + 42
  | contrived (_::_) n = sum [1, 2, 3] n

This produces the following error:

stdIn:1.5-5.41 Error: types of rules don't agree [literal]
  earlier rule(s): 'Z list * int -> int
  this rule: 'Z list * int list -> int list
  in rule:
    (_ :: _,n) => (sum (1 :: <exp> :: <exp>)) n

Sure, we’re finding the problem eventually, but I dare you to track that one down without squinting hard, particularly if the definition of `sum` is in a different module.

This example *is* contrived. However, I have run into very similar issues when trying to write real code, and that’s what bothers me. If people aren’t religious about annotating their types — and, unlike Haskell, ML doesn’t make a point of encouraging this — it is very easy to dig yourself into a very confusing and hard-to-trace error just by virtue of repeated false inferences.

My larger objection is to your assertion that partial annotation somehow isn’t “real” type inference. This seems silly. The purpose of type inference isn’t to prevent you from writing types. The purpose is to help get the types cross-checked and confirmed. How much of the automation you choose to use is completely up to you. None of this absolves you from looking at the answes.

Annotations are not a panacea either — and particularly not in a language having implicit coercions. I cannot tell you how many bugs in the SVR4 kernel implementation were due to disagreements between two structures concerning which integer size to use. All the annotations were there, but the errors were not caught automatically. Needless to say these were not easy to track down.

I suppose the thing to say here is that all languages have shortcomings. The test of ML, in part, is that the types of errors you decry are rarely observed in the wild.

The point has been raised that ML (and Haskell) allows you to explicitly annotate types in the function declaration. So my example could be redeclared like this:

fun sum nil init:int = init
| sum (hd::tail) init = hd + (sum tail init)

This simple change is sufficient to avoid all of the issues with cons vs plus in the typo. However, this is not really type inference anymore. Certainly the compiler is inferring a number of types in this expression, but it is no longer inferring *everything*. In both my ML and my Scala examples, I used the *least* type annotations possible to still allow things to compile. Thus, in both examples I relied as heavily as possible on type inference in the respective languages. By annotating a type, you’re effectively overriding the type inference and giving it explicit information to draw on.

I suppose type annotations in ML really are a matter of policy enforcement as much as any other convention is. Hindley/Milner is a very powerful form of type inference which allows a lot of bad code (like my contrived example). It is a bit of a subjective thing, but I tend to believe that a language should not be *too* enabling. It’s like static vs dynamic typing. Dynamic type systems are inarguably more flexible due to the removal of static constraints, but are they really better in a real-world application? You can certainly make policies that stipulate documentation and “good design” as it relates to potential abuse of the dynamic type system (e.g. runaway duck typing), but the potential still remains for something very bad to happen. ML allows many dubious practices (such as not annotating function params etc), and when the compiler doesn’t enforce something, lazy programmers tend to take advantage of the loophole.

As a matter of record, ML doesn’t require you to type everything into the interpreter. There are tools such as Compilation Manager which allow the compilation of such ML functions without actually spitting out the type signature at compile-time. It is quite conceivable that a developer could write a function like my example, compile it using a tool such as CM, and never realize the issue until some point later in the code when he attempted to use the function. Once again, the error is separated from the cause.

@Martin

I’m personally quite pleased with Scala’s type inference and really it’s type system in general. There are certainly times when I *wish* it had more universal type inferencing, but in general I prefer it just the way it is. The notable exception of course being recursive methods.

As to MLF, I was actually pointed that direction shortly after I wrote this article by a professor in type theory with whom I correspond. Remy’s premise seems to be very similar to the point I was trying to make in this article, except he did more than just point out the problem and actually developed a complete language extension to fix the “problem”.

Careful about throwing out terms like “Bad Thing”. Bad for whom, and to what end? A perfectly valid reply to your subject line would be: “No it isn’t.” It’s actually quite useful.

Imagine you’d write a (stupid) function to concatenate two lists:

def concat(xs, ys) = xs match {
case nil => ys
case hd::tl => hd::concat(tl, ys)
}

What’s the type of the function? Is it

def concat[T](xs:List[T], ys:List[T]):List[T] = xs match {
case nil => ys
case hd::tl => hd::concat(tl, ys)
}

Without subtyping this might be the right type, but with subtyping you might prefere something like this:

def concat[T, U ys
case hd::tl => hd::concat(tl, ys)
}

This might be the right type, but the type inferencer could as well infere this:

def concat[T, U ys
case hd::tl => hd::concat(tl, ys)
}

This is a valid type for the function, but IMO has no advantage over the previous one. But perhaps this is the type thet will be infered. And now imagine a more complicated function than this very simple one. Especialy in combination with higher order functions you might get uncomprehensably complex types.

You annotated the top-level of Scala but did not do so with the ML version. You concretely gave more information to the Scala compiler than the ML compiler.

In Haskell, since this is the language I’m currently most familiar with, I would annotate it as follows. Note that typically accumulator-based recursion is not used in Haskell, but I will do so now to keep the changes minimal. Note also that this function works for any number type, not just ints, thereby making it more flexible than the Scala version. I renamed the function as the function ’sum’ already exists.

mysum :: (Num a) => [a] -> a -> a
mysum [] init = init
mysum (x:xs) init = x + (sum xs init)

If we now introduce the error you introduced:
mysum :: (Num a) => [a] -> a -> a
mysum [] init = init
mysum (x:xs) init = x:(sum xs init)

You will now get a compiler error on the third line.