Comment by lambdawitch | Hacker News Reader

Comment by lambdawitch | Hacker News Reader

Parent Full thread

> Inferring types of function parameters and results isn't as useful. Combined with generics, it gets really complicated.

I wonder why you think so? The inferred types in a language like Haskell or OCaml are almost always exactly what the programmer would have written. So long as a language has principle type inference, the worst case is that the inferred type is a bit more general than you expected.

> Also, whole-program type inference and separate compilation inherently conflict.

There is no conflict here, actually. All type variables in definitions exported from a module are generalizable. As such, no uses in other modules will further refine those types.

> I wonder why you think so? The inferred types in a language like Haskell or OCaml are almost always exactly what the programmer would have written

I have no experience with ML-using languages but in Scala, which has inferior but still useful type inference, it is recommended to add explicit types to public functions/methods because otherwise, implementation details or errors might alter the signature.

Take for example:

    data Tree = Node Leaf Leaf | Leaf Integral
    makeEmptyTree x => Leaf x

I assume `Leaf` will be inferred as a type, while the programmer might have meant `Tree` to be the public API. (or vice-versa)

No, Leaf isn't a type.

In ML, constructors aren't subtypes of a sum type. And that's a good thing.

This is largely to do with subtyping and it's well known that systems with user-defined nominal subtyping don't have good inference. Scala's inference is really in the middle: squarely better than C/Java and much worse than Haskell/OCaml.

Reply on news.ycombinator.com