3 ms·
> 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 inferr
by lambdawitch 9y ago
> 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.
- dtech 9y ago> 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)
- pdexter 9y agoNo, Leaf isn't a type.
- catnaroek 9y agoIn ML, constructors aren't subtypes of a sum type. And that's a good thing.
- tel 9y agoThis 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.