oh, erm, maybe i was not clear enough. i did not mean that imperative languages are better. far from it. i meant that their compile-time error messages show more lexical miswritings than complex mistakes. their complex mistakes cause runtime-errors. and with logs and debugs of the running program you find mainly "the first abnormal behaviour that is caused by that bug". so, the complex compile-error messages of haskell code are unusual for imperative languages.
- marc Am Mittwoch, 29. Juni 2005 05:20 schrieb Seth Kurtzberg: > 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@haskell.org > >>http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >> > >> > >> > >> > >_______________________________________________ > >Glasgow-haskell-users mailing list > >Glasgow-haskell-users@haskell.org > >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > > > > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users