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,

        <b
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Reply via email to