GHC poor type-checker error message

[isaacdupree]

Here is a very tricky GHC (6.4) error message I found.
 I have simplified the context from where I found it,
but the error is basically the same (still rather less
confusing than the real thing, where Value ::
[TString], TString :: [(String,Textdomain)], and error
messages talked about, e.g., [[([Char],Textdomain)]]
instead of [[Char]]). I had to run the original through
Hugs to find my mistake there. Here is the code:

> import Data.List(intersperse)
> type Value = String
> -- unifyEnd :: [key] -> [Value] -> [Value]
> -- this example assumes (length ks <= length vs)
> unifyEnd ks vs =
>	let (fvs,evs) = splitAt (length ks - 1) vs
>	in fvs ++ concat (intersperse "," evs)

Here is the GHC-6.4 error message:
BadErrorMessage.lhs:10:41:
    Couldn't match `[Char]' against `Char'
      Expected type: [[Char]]
      Inferred type: [Char]
    In the second argument of `intersperse', namely `evs'
    In the first argument of `concat', namely
`(intersperse "," evs)'

The error message when the type signature is
uncommented at least might lead to less pursuing of the
wrong things, claiming the literal `","' is in error
instead, but does not get to the location of the error.

The Hugs error, while not perfect, has got the location
correct: it shows me the part I erred in:
ERROR "BadErrorMessage.lhs":8 - Type error in application
*** Expression     : fvs ++ concat (intersperse "," evs)
*** Term           : fvs
*** Type           : [[Char]]
*** Does not match : [Char]

I had forgotten to put [ ] around concat (...), i.e.
	fvs ++ [concat (intersperse "," evs)]
is the corrected fragment of the definition.

GHC did not appear to realize that the two arguments to
'intersperse' were currently consistent with each
other, given intersperse's type signature of a -> [a]
-> [a], but would not be if the type of the one claimed
to be in error were changed to the "expected" type. (If
it could say that they were both the wrong type, that
would be another choice it had that makes sense, but
that would be two human errors, perhaps less likely
than one.)

[guest]

i will be glad to see such type of problems fixed, although probably in 6.8.1. non-friendly error messages are still the problem with ghc, although most times it's enough to see line number so rather quickly find real problem

[simonmar]

tcfail140 demonstrates another class of poor type error messages.

[simonpj]

See also #956

[simonpj]

See also #589

[igloo]

We get the same error in 6.12.

[simonpj]

I agree that the error message could be better, but fixing that is a research question. Unlike some of the other type-error-message tickets, this one is not egregiously awful, and I can't see a way to improve it much.

So I think I'll close the ticket, not because it's vacuous, but because I can't see us fixing it in the forseeable future.

Simon

[isaacdupree]

Indeed. I looked at it again. Now that I understand the general modus operandi of Hindley-Milner type inference, I see how it is far from obvious for the type-checker/inferrer/errorer how to make the judgments that I'd been hoping were straightforwards :-)