#511 GHC poor type-checker error message
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.)