Finally, I've always liked how GHC helpfully explains the context in which the error occurs ("in the second argument ... in the expression ... etc"), but I think we've been outclassed by other compilers that just
#13670: Improving Type Error Messages -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): print the offending line with the error underlined. We could adopt this strategy. Thanks to @Rufflewind GHC 8.2 does precisely this. e.g., {{{ hi.hs:9:33: error: • Couldn't match type ‘a’ with ‘b’ ‘a’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at hi.hs:8:11-38 ‘b’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at hi.hs:8:11-38 Expected type: List b Actual type: List a • In the second argument of ‘ListElement’, namely ‘xs’ In the expression: ListElement (f x) xs In an equation for ‘fmap’: fmap f xs = ListElement (f x) xs • Relevant bindings include xs :: List a (bound at hi.hs:9:10) f :: a -> b (bound at hi.hs:9:8) fmap :: (a -> b) -> List a -> List b (bound at hi.hs:9:3) | 9 | fmap f xs = ListElement (f x) xs | ^^ }}} (with color even!) Arguably the "in the second argument of ..." text can now be dropped, but this won't be done for 8.2.
(Related: it seems redundant to provide this context if the user is inside their editor rather than at the command-line. What if we had a flag --editor-mode to prune such redundancies?)
I think we are now getting into the problem of more structured (in the machine-readable sense) error messages. I suggest an approach to attacking this problem in ticket:8809#comment:3. Recently this project has been un- stuck by Alfredo Di Napoli, who has been doing some great work reconciling GHC's `Pretty` module with the upstream `pretty` library. This will allow us to use `pretty`'s annotated pretty-printer to embed Haskell values in error messages, giving consumers the ability to pick out exactly the details that they want to show. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13670#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler