Errr, sorry, I only saw “higher-kinded”, not “higher-ranked”. But, of course, you are right.
> That is true, but already type inference for rank-3 polymorphism is undeciable, hence also System F polymorphism.
Let polymorphism covers 95% of what most programmers need. So if a language designer feels particularly risk-averse (a perfectly legitimate position), they can provide just let polymorphism and ML-style type inference, and then call it a day.
Of course, higher-ranked polymorphism is a nice thing to have, and you can require type annotations when you use more (as Haskell does).
> In practise, Haskell needs only few kind-annotations to make kind inference possible.
A more serious problem with higher-kinded types IMO is that they wouldn't interact very well with an ML-style module system, where you can define an abstract type whose internal implementation is a synonym. `newtype` is an ugly hack.
provide just let polymorphism
and ML-style type inference
My main caveat would be that even a basic language needs a mechanism to glue related code together, objects, modules, structs with row-typing, existentials, not sure. But something.
While not perfect, I think ML's solution is pretty reasonable: a separate module language, whose complexity doesn't infect the core language.
That's interesting. Why is that?
In practise, Haskell needs only few kind-annotations to make kind inference possible. This is helped by unannotated kind variables having kind * in Haskell (IIRC).