<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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).<br>
<br>
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.<br>
<br>
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.    <span
 class="moz-smiley-s1"><span> :-) </span></span>      )<br>
<br>
Marc A. Ziegert wrote:
<blockquote cite="mid200506290510.50387.coeus@gmx.de" type="cite">
  <pre wrap="">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
  </pre>
  <blockquote type="cite">
    <pre wrap="">1 module Test7 where
2
3 len' xs = head (xs) + (length xs)
4 o = len' "GH"
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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] -&gt; [Int]
                    :: [Char]
 HINT: type of      : (len')
       is caused by   missing explicit type declaration
                      len' :: [Int] -&gt; [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] -&gt; [Int]
                    :: [Char]
 HINT: type of      : (g y)
       is caused by    g   :: a -&gt; [a] -&gt; [a]
                         y :: Int
 HINT: type of      : (f x)
       is caused by    f   :: X -&gt; 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:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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 &gt; 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) =&gt; a as its parameter.

Code:

1 module Test4 where

3 k :: Int -&gt; 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
<a class="moz-txt-link-abbreviated" href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a>


    </pre>
  </blockquote>
  <pre wrap=""><!---->_______________________________________________
Glasgow-haskell-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a>

  </pre>
</blockquote>
<br>
</body>
</html>