Opened 2 years ago
Last modified 2 years ago
#13670 new bug
Improving Type Error Messages
Reported by: | gridaphobe | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Compiler | Version: | 8.0.1 |
Keywords: | TypeErrorMessages | Cc: | |
Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |
Type of failure: | None/Unknown | Test Case: | |
Blocked By: | Blocking: | ||
Related Tickets: | Differential Rev(s): | ||
Wiki Page: |
Description
I was reading through https://medium.com/@sjsyrek/some-notes-on-haskell-pedagogy-de43281b1a5c the other day, and noticed a pretty gnarly error message produced by the following code
{-# LANGUAGE InstanceSigs #-} data List a = EmptyList | ListElement a (List a) deriving Show instance Functor List where fmap :: (a -> b) -> List a -> List b fmap f xs = ListElement (f x) xs
list.hs:8:49: 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 list.hs:7:11 ‘b’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at list.hs:7:11 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 (ListElement x xs) = ListElement (f x) xs • Relevant bindings include xs :: List a (bound at list.hs:8:25) x :: a (bound at list.hs:8:23) f :: a -> b (bound at list.hs:8:8) fmap :: (a -> b) -> List a -> List b (bound at list.hs:8:3)
I think there are a few things we could do better here.
- The biggest issue IMO is that the key piece of information, the mismatch between
List a
andList b
is stuck right in the middle of the error message, obscured by GHC's attempt to be helpful by pointing out the provenance ofa
andb
. The mismatch should be front and center, so users see it without having to dig through a wall of text! I think just swapping the order of the expected/actual types and the tyvar provenance would be a big improvement.
list.hs:8:49: error: • Couldn't match type ‘a’ with ‘b’ Expected type: List b Actual type: List a ‘a’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at list.hs:7:11 ‘b’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at list.hs:7:11 • In the second argument of ‘ListElement’, namely ‘xs’ In the expression: ListElement (f x) xs In an equation for ‘fmap’: fmap f (ListElement x xs) = ListElement (f x) xs • Relevant bindings include xs :: List a (bound at list.hs:8:25) x :: a (bound at list.hs:8:23) f :: a -> b (bound at list.hs:8:8) fmap :: (a -> b) -> List a -> List b (bound at list.hs:8:3)
But there's more we can do!
- The rust compiler does this very nice thing where it attaches helpful notes that relate to the error to other source spans. The benefit here is that editors can then highlight multiple spans to produce a nicer visual. In our case, the provenance of the tyvars feels like such a helpful note, rather than a core part of the error message.
list.hs:8:49: error: • Couldn't match type ‘a’ with ‘b’ 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 (ListElement x xs) = ListElement (f x) xs • Relevant bindings include xs :: List a (bound at list.hs:8:25) x :: a (bound at list.hs:8:23) f :: a -> b (bound at list.hs:8:8) fmap :: (a -> b) -> List a -> List b (bound at list.hs:8:3) list.hs:7:11: note: • ‘a’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b list.hs:7:11: note: • ‘b’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b
Now the editor will highlight the ill-typed xs
in red, with a popup that just provides the error; and the type for fmap
in another color (usually blue it seems), with a popup that explains the provenance of the tyvars. (We might also want to separate the "relevant bindings" into a helpful note.)
I believe many linter packages for editors are already setup to distinguish between errors and helpful notes, so this would be a really simple and free improvement.
- 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 print the offending line with the error underlined. We could adopt this strategy. (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?)
Change History (3)
comment:1 Changed 2 years ago by
Keywords: | TypeErrorMessages added |
---|
comment:2 Changed 2 years ago by
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 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.
comment:3 Changed 2 years ago by
Replying to simonpj
I think you should wait a little.
There is a contradiction to correct this without first correcting ticket #9173
.
On the other hand there is more to remove.
See the comment n ° 2 that I wrote in the ticket #13902
.
Many people agree to review and improve the error messages. I think that this must be done in a collegial way and not punctually.
This correction would be made once and for all and not a sudden blow.
All good ideas. (1) is particularly easy to do. Any volunteers?