On Thu, Mar 27, 2014 at 6:12 PM, Semen Trygubenko / Семен Тригубенко
However, I believe both types should be mentioned, as one is as likely to be wrong as the other. If we are outputting it like that (i.e., one of the two, not both) and care about the amount of output, why are we not outputting the less complex type of the two types involved in a mismatch? r would certainly win that contest.
IMHO, I don't think word "expected" is a great word to use here. (length . head) expects to be fed [[a2]] as much as r expects it should be passed into to functions that take Int. ghc should "expect" us to change (length . head) to take Int as much as it "expects" us to fix r to be of type [[a2]].
I agree that the terms used are less than ideal, but there IS a difference between the two types that's worth communicating. The cause of this error is because you have a thingie and a place to put a thingie and they don't fit together. It's essentially a "square peg in a round hole" error, and "Can't fit 'square peg' into 'round hole'" is much easier to understand than "Can't match 'square' with 'round'. Expected shape: round Actual shape: square". But 'round' and 'square' aren't interchangeable so they shouldn't be treated as such in the message. While it's easy to learn and interpret what the current message means, I think it would be far more helpful for newcomers if it was reported more clearly that 1) they have an expression known to have some type 'A' 2) which they've used in a context that expects some type 'B' and 3) GHC can't unify A and B to get some type C that works for both. Perhaps even displaying the surrounding context with the offending subexpression replaced with '_'? Sort of mimicking the way the typed holes stuff looks, I guess. If nothing else though, it would probably help to clarify that it's the surrounding code that 'expects' a particular type, rather than giving the impression that GHC has an opinion on the matter and expects a particular type. GHC just wants them to match, that's all. - C.