Feedback on Error messages in ghc.
Seth Kurtzberg
seth at cql.com
Tue Jun 28 23:20:03 EDT 2005
I don't disagree with the main thrust, but the idea that imperative
language are, in general, better about error messages is not, in my
opinion, true. There is a large variation, of course, but for certain
types of errors in an imperative language the compiler simply can't get
a correct handle on what is wrong (because of ambiguities that cannot be
removed).
I, and I'm sure everyone else, would always be in support of more
detailed error messages, and I agree that the examples cited increase
the clarity. In my opinion this increase is significant and worth doing.
I just wanted to correct any assumption that imperative language don't
suffer from error message problems. Fundamentally, they suffer more,
and are in many cases impossible to fix. In my experience GHC error
locations always have some relationship to the error in coding, although
of course the error message may at times be hard to interpret because
the programmer believes he has coded a function with a particular
signature but, in fact, has coded the function with a different inferred
type. (Of course we all always explicitly specify function signatures
and avoid this problem entirely. :-) )
Marc A. Ziegert wrote:
>greetings.
>
>i have to agree with Peter. it's really no fun to read the error messages.
>
>
>i do not have a big problem with those; but i'm not a newbie anymore, and as newbie...
>i always just understood nothing more than that single given LINENUMBER within all that output-spam. well, most times it was enough.
>
>the trick is:
>to throw the code against the --Wall tests whether it is al dente or crumbly.
>the solution is to type the types and to look about where the bugs are running.
>hey, of course, they like crumbs. ;-)
>
>especially for newbies it is really confusing, that the compiler output does not always show the real position of the bug (like in imperative languages),
>but the first found abnormal behaviour that is caused by that bug (like in runtime errors).
>
>now that i saw that clean hugs output, i thought about it a little bit more:
>one does not need pages of error-description written in the style of... juristic blah,
>but a clear description about what's wrong and maybe some hints to solve it.
>
>
>
>in that given example
>
>
>>1 module Test7 where
>>2
>>3 len' xs = head (xs) + (length xs)
>>4 o = len' "GH"
>>
>>
>
>i would prefer an output like this:
>
>TYPE MISMATCH in "Test7.hs": line 4, col 5
> in Expression : len' "GH"
> between Function : len'
> and Parameter : "GH"
> with Types :: [Int] -> [Int]
> :: [Char]
> HINT: type of : (len')
> is caused by missing explicit type declaration
> len' :: [Int] -> [Int]
>
>well, if we replace ("GH") with (f x) and (len') with (g y) then it should look like
>
>TYPE MISMATCH in "Test7.hs": line 4, col 5
> in Expression : g y (f x)
> between Function : g y
> and Parameter : (f x)
> with Types :: [Int] -> [Int]
> :: [Char]
> HINT: type of : (g y)
> is caused by g :: a -> [a] -> [a]
> y :: Int
> HINT: type of : (f x)
> is caused by f :: X -> String
> x :: X
> HINT: expression : f
> could be mistaken. (Compile with --Wall for more hints.)
>
>
>well, i do not know how hard it is to implement that, but at least without hints it is less irritating than the old style.
>
>
>
>
>
>- Marc
>
>
>
>Am Dienstag, 28. Juni 2005 21:43 schrieb Peter A Jonsson:
>
>
>>Hello,
>>
>>I read the summary of the survey and noticed you wanted feedback on
>>where error messages could be improved. I looked up some (simple)
>>examples of type errors and ran them through ghc. I do not make any
>>claims to be an HCI expert, just a mere mortal with an opinion.
>>
>>Code:
>>
>>1 module Test2 where
>>2
>>3 fib n = if (3 > n) then 1 else (fib (n - 1) + fib (n - 2))
>>4 k = fib 's'
>>
>>Error message:
>>
>>Test2.hs:4:
>> No instance for (Num Char)
>> arising from use of `fib' at Test2.hs:4
>> In the definition of `k': k = fib 's'
>>
>>This isn't a bad error message in my humble opinion, it does pinpoint
>>that I'm doing something wrong in line 4, and that there isn't an
>>instance for Num Char doesn't come as a surprise. However I think it
>>could have been more helpful by telling me that I tried to pass a Char
>>to a function which expected an (Ord a, Num a) => a as its parameter.
>>
>>Code:
>>
>>1 module Test4 where
>>2
>>3 k :: Int -> Int
>>4 k l = 2.0*l
>>
>>Error message:
>>
>>Test4.hs:4:
>> No instance for (Fractional Int)
>> arising from the literal `2.0' at Test4.hs:4
>> In the first argument of `(*)', namely `2.0'
>> In the definition of `k': k l = 2.0 * l
>>
>>One reason this kind of error could happen is an inexperienced user
>>declaring the wrong type for his function, or not knowing that 2.0
>>would be interpreted as a Fractional.
>>
>>Code:
>>
>>1 module Test7 where
>>2
>>3 len' xs = head (xs) + (length xs)
>>4 o = len' "GH"
>>
>>Error message:
>>
>>Test7.hs:4:
>> Couldn't match `Int' against `Char'
>> Expected type: [Int]
>> Inferred type: [Char]
>> In the first argument of `len'', namely `"GH"'
>> In the definition of `o': o = len' "GH"
>>
>>I ran this through Hugs version November 2002 and got this error
>>message:
>>
>>ERROR "Test7.hs":4 - Type error in application
>>*** Expression : len' "GH"
>>*** Term : "GH"
>>*** Type : String
>>*** Does not match : [Int]
>>
>>I find the Hugs message more clear, but that might be my background.
>>
>>Code:
>>
>>1 module Test8 where
>>2
>>3 f = head 3
>>
>>Error message:
>>
>>Test8.hs:3:
>> No instance for (Num [a])
>> arising from the literal `3' at Test8.hs:3
>> Possible cause: the monomorphism restriction applied to the following:
>> f :: a (bound at Test8.hs:3)
>> Probable fix: give these definition(s) an explicit type signature
>> In the first argument of `head', namely `3'
>> In the definition of `f': f = head 3
>>
>>This one I find outright scary. For "wrong = div 3 8 + 1/2" it gives
>>an error message that somewhat helps me guess the error, but the above
>>doesn't even come close to helping me.
>>
>>/ Peter
>>
>>
>>_______________________________________________
>>Glasgow-haskell-users mailing list
>>Glasgow-haskell-users at haskell.org
>>http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>>
>>
>_______________________________________________
>Glasgow-haskell-users mailing list
>Glasgow-haskell-users at haskell.org
>http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/glasgow-haskell-users/attachments/20050628/7f962904/attachment.htm
More information about the Glasgow-haskell-users
mailing list