Ticket #451 (new bug: None)

Opened 3 years ago

Last modified 2 months ago

GHC poor type-checker error message

Reported by: isaacdupree Assigned to:
Priority: normal Milestone: _|_
Component: Compiler (Type checker) Version: 6.4
Severity: normal Keywords:
Cc: Bulat.Ziganshin@gmail.com Difficulty: Unknown
Test Case: tcfail140 Operating System: Unknown/Multiple
Architecture: Unknown/Multiple

Description (Last modified by simonpj)

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.)

Change History

01/04/06 07:55:04 changed by simonpj

  • status changed from assigned to new.
  • description changed.
  • difficulty set to Unknown.
  • architecture set to Unknown.
  • owner changed from nobody to simonpj.
  • os set to Unknown.

01/23/07 07:24:30 changed by igloo

  • testcase changed.
  • milestone set to 6.8.

07/03/07 02:59:57 changed by guest

  • cc set to Bulat.Ziganshin@gmail.com.

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

07/06/07 01:10:20 changed by simonmar

  • testcase set to tcfail140.

tcfail140 demonstrates another class of poor type error messages.

11/12/07 05:27:03 changed by simonmar

  • owner deleted.
  • milestone changed from 6.8 branch to _|_.

11/12/07 08:03:34 changed by simonpj

See also #956

11/14/07 00:00:51 changed by simonpj

See also #589

09/30/08 08:37:14 changed by simonmar

  • architecture changed from Unknown to Unknown/Multiple.

09/30/08 08:51:00 changed by simonmar

  • os changed from Unknown to Unknown/Multiple.