I don't think this is as easy as you make it seem. A whole bunch of problems in typing and deduction are undecidable in the general case. (Don't know about this one, but just saying.)
Also, you seem a little aggressive toward "Haskellers". I'm sure you didn't mean to be! :)
The thing with "undecidable in the general case" is that 80% if the time you can just heuristically guess an be right. Most bugs are shallow. Typos, forgetting operators etc. And even if the guess is just plain wrong, I think that a wrong simple guess is most of the time better at nudging the learner in the direction of fixing the mistake than an incomprehensible type deduction explanation... And if it's not you can always have it under some kind of "details". And no, I don't think this is "a job for the IDE"... this would be Java-think :)
...and that't the thing, when guessing what's actually wrong, syntax can help a lot. Things like having the equivalent of an auto-curry-on-off toggle at the syntactic level, would make guessing at least 50% easier. And other little things too. I think ML-lamnguages tend to shoot themselves in the foot here. C-like syntax has a clear advantage when it comes to enabling guessing and heuristics.
I didn't mean to be agressive, I love the concepts behind Haskell... this is why I hate the "little things" that ruin it and make it almost unusable for average "don't make me think too much right now" type developers (like me after some sleep deprivation or a couple of beers or during a "this bug needs to be fixed by yesterday morning" sprint :) ).
Jonathan Blow is creating a new language with an interesting idea for this: if you have 'fn f(a:$T, b:T) -> T', the $ means: T is a polymorphic (generic) type and 'a' is the parameter which defines the value of the type so if there is a type mistake you get nicer error message.
Also, you seem a little aggressive toward "Haskellers". I'm sure you didn't mean to be! :)