GHC's error messages are too verbose?
I've long wondered why GHC issues such prolix error messages when it
runs into a problem. Here's a representative example from some hacking
I'm currently doing:
src/Network/Hackage/CabalPackage/Setup.hs:68:5:
Couldn't match expected type `(RpmFlags, [String])'
against inferred type `()'
Expected type: IO (RpmFlags, [String])
Inferred type: IO ()
In the expression:
(when (not (null unknown)))
$ (do hPutStrLn stderr "Unrecognised options:"
mapM_ (hPutStrLn stderr) unknown
exitWith (ExitFailure 1))
This might not look like a terribly long error, but that's because I've
snipped a bunch of context that GHC also prints:
In the expression:
do let (os, args', unknown, errs)
= getOpt' RequireOrder options args
opts = foldl (flip ($)) emptyRpmFlags os
(when (rpmHelp opts))
$ (do printHelp stdout
exitWith ExitSuccess)
(when (not (null errs)))
$ (do hPutStrLn stderr "Errors:"
mapM_ (hPutStrLn stderr) errs
exitWith (ExitFailure 1))
(when (not (null unknown)))
$ (do hPutStrLn stderr "Unrecognised options:"
mapM_ (hPutStrLn stderr) unknown
exitWith (ExitFailure 1))
This length is on the modest side for a block of monadic code. With a
longer chunk of code, individual error messages can easily stretch to
dozens of lines long, due purely to GHC printing context information
that amounts to repeating my source code back at me.
I don't understand the motivation behind this verbosity. Clearly, a
little bit of context is helpful, so I can see which expression GHC is
objecting to, but why repeat the entire surrounding chunk of code back
at me, when I already have the file name and line number, and the
original code that caused the error?
Compilers for other languages seem content with as little as one line of
output per error (which I am not advocating), or a few lines of source
with the problem highlighted, but I rarely see more. Hugs also tends
towards the terse side, but I've never found this to be a problem.
Cheers,
Hi
I've long wondered why GHC issues such prolix error messages when it runs into a problem.
I am primarily a Hugs user, compiling and running only with GHC once the code works, and only if I really need the speed - which is quite rare. but I've been hacking a project in GHCi recently (requiring template haskell), and I found the GHC error messages way too verbose.
Compilers for other languages seem content with as little as one line of output per error (which I am not advocating), or a few lines of source with the problem highlighted, but I rarely see more. Hugs also tends towards the terse side, but I've never found this to be a problem.
The most important thing in an error message for me is the line number. Next I want to see the type of error - syntax, type, instance etc. Then I want to see just a few lexemes of context so I can find where to start looking. If after all that I didn't figure out where the error was, I'd want more context - but I rarely want it with Hugs. I much prefer the Hugs error messages, although this may be experience with Hugs, rather than an issue with GHC. Thanks Neil
On Sat, 2007-04-14 at 11:40 +0100, Neil Mitchell wrote:
I much prefer the Hugs error messages, although this may be experience with Hugs, rather than an issue with GHC.
I think GHC(i)'s error messages are great. Whenever my students (and sometimes I) don't understand Hugs's error messages I suggest they try GHCi and that usually gives something a lot better. Duncan
The verbosity is both a boon and a hinderance. Personally, I don't mind the extra information, but I'm fairly certain it causes alarm in many newbies (judging from questions on #haskell). For example, a simple type error like using (+) with a Char results in: No instance for (Num Char) arising from the literal `1' at file:pos Possible fix: add an instance declaration for (Num Char) In the first argument of `(+)', namely `1' In the expression: 1 + 'c' In the definition of `it': it = 1 + 'c' That's a lot of terminology a typical newbie might not understand yet, also, the suggested resolution is well off the mark. I'm not saying that the error messages should be dumbed down necessarily, but that the beginner's perspective may be worth considering. -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org
Two thoughts on this error-message thread. 1. It'd be easy to add a flag to trim the number of levels of context you get. It'd mean yet another flag though. 2. Bryan got a rather long chunk of program text. GHC tries to trim the size of program chunks by printing "..." after a certain "depth". But this depth mechanism isn't working well for Bryan's example. This should not be at all hard to fix -- it look as it may be to do with do-notation. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Neil Mitchell | Sent: 14 April 2007 11:40 | To: Bryan O'Sullivan | Cc: glasgow-haskell-users@haskell.org | Subject: Re: GHC's error messages are too verbose? | | Hi | | > I've long wondered why GHC issues such prolix error messages when it | > runs into a problem. | | I am primarily a Hugs user, compiling and running only with GHC once | the code works, and only if I really need the speed - which is quite | rare. but I've been hacking a project in GHCi recently (requiring | template haskell), and I found the GHC error messages way too verbose. | | > Compilers for other languages seem content with as little as one line of | > output per error (which I am not advocating), or a few lines of source | > with the problem highlighted, but I rarely see more. Hugs also tends | > towards the terse side, but I've never found this to be a problem. | | The most important thing in an error message for me is the line | number. Next I want to see the type of error - syntax, type, instance | etc. Then I want to see just a few lexemes of context so I can find | where to start looking. If after all that I didn't figure out where | the error was, I'd want more context - but I rarely want it with Hugs. | | I much prefer the Hugs error messages, although this may be experience | with Hugs, rather than an issue with GHC. | | Thanks | | Neil | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
This reminds me of the (closed) bug report about long error messages: http://hackage.haskell.org/trac/ghc/ticket/719 I'm not convinced the original bug is fixed, and it seems somewhat similar to Bryan's example, being a do-expression. Cheers, Simon Simon Peyton-Jones wrote:
Two thoughts on this error-message thread.
1. It'd be easy to add a flag to trim the number of levels of context you get. It'd mean yet another flag though.
2. Bryan got a rather long chunk of program text. GHC tries to trim the size of program chunks by printing "..." after a certain "depth". But this depth mechanism isn't working well for Bryan's example. This should not be at all hard to fix -- it look as it may be to do with do-notation.
Simon
| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Neil Mitchell | Sent: 14 April 2007 11:40 | To: Bryan O'Sullivan | Cc: glasgow-haskell-users@haskell.org | Subject: Re: GHC's error messages are too verbose? | | Hi | | > I've long wondered why GHC issues such prolix error messages when it | > runs into a problem. | | I am primarily a Hugs user, compiling and running only with GHC once | the code works, and only if I really need the speed - which is quite | rare. but I've been hacking a project in GHCi recently (requiring | template haskell), and I found the GHC error messages way too verbose. | | > Compilers for other languages seem content with as little as one line of | > output per error (which I am not advocating), or a few lines of source | > with the problem highlighted, but I rarely see more. Hugs also tends | > towards the terse side, but I've never found this to be a problem. | | The most important thing in an error message for me is the line | number. Next I want to see the type of error - syntax, type, instance | etc. Then I want to see just a few lexemes of context so I can find | where to start looking. If after all that I didn't figure out where | the error was, I'd want more context - but I rarely want it with Hugs. | | I much prefer the Hugs error messages, although this may be experience | with Hugs, rather than an issue with GHC. | | Thanks | | Neil | _______________________________________________ | 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
participants (6)
-
Bryan O'Sullivan -
Duncan Coutts -
Matthew Danish -
Neil Mitchell -
Simon Marlow -
Simon Peyton-Jones