3 ms·
I wouldn't call ML popular, and in Haskell you have type classes, which have undecidable type inference. You can write `show (read str)` in Haskell for example,
by quchen 11y ago
I wouldn't call ML popular, and in Haskell you have type classes, which have undecidable type inference. You can write `show (read str)` in Haskell for example, which parses `str` and then converts it back to `String` again. But the compiler cannot infer which type you want to parse to: is the input an Int, a Double, a JSON object, any other read/showable format? In these (rare) cases, you need explicit type annotations.
(Without type classes, type inference is decidable in Haskell.)
- mafribe 11y agoAs an aside, Hindley–Milner is DEXPTIME-complete, and indeed you can write 5 line programs that exhibit the worst-case behaviour. That's as bad a worst-case behaviour as undecidability for all practical purposes. That said, in practise, HM type inference tends to be very fast, because the worst-case behaviour only shows up in rather artificial programs that human programmers would normally not write. If you bound the depth of let-nesting, HM is polynomial.
- quchen 11y agoYou're correct on the theoretical side, and writing a value whose type makes GHC crash is fairly easy. But in multiple years of Haskell, I did not encounter nor have I heard of a practical case in which type inference time was a performance issue, let alone a bottleneck or problem.