haskell/error-messages

Perhaps you meant a :: Maybe Int

Opened this issue · 6 comments

mpscholten commented

Given this code:

a :: Just Int
a = Just 5

GHC errors with:

Not in scope: type constructor or class 'Just'A data constructor of that name is in scope; did you mean DataKinds?

A better error message would be:

Perhaps you meant a :: Maybe Int?
Not in scope: type constructor or class 'Just'
A data constructor of that name is in scope; did you mean DataKinds?

Suggested on reddit: https://www.reddit.com/r/haskell/comments/kgvdon/improving_haskell_ghc_error_messages/gghjajf/?utm_source=reddit&utm_medium=web2x&context=3

noughtmare commented

I would keep the general problem as the first line, maybe like this:

Not in scope: type constructor or class 'Just'
A data constructor of that name is in scope.
Did you mean to use the corresponding type constructor: 'Maybe'?
Or for advanced users: did you mean to use DataKinds?

Also, a bit unrelated, shouldn't the or class part of the first line be removed? is it possible to use a class in this position?

goldfirere commented

I have a few small perturbations to the suggested text (which I very much like):

Not in scope in types: 'Just'
However, a data constructor of that name is in scope.
Did you mean to use the corresponding type constructor 'Maybe'?
Or for advanced users: did you mean to enable DataKinds?

I've sidestepped the "type constructor or class" bit. (It could also be a type synonym, or type family, or data family.)

I like the "for advanced users". Maybe that can be a new pattern, where we label a suggestion as "for advanced users".

  • 👍7
mpscholten commented

I like the "for advanced users". Maybe that can be a new pattern, where we label a suggestion as "for advanced users".

Love the idea 👍

adamgundry commented

The "for advanced users" idea sounds good. It's a not infrequent complaint that GHC's error messages suggest things that are rarely a good idea unless you really know what you are doing.

Perhaps such suggestions could be marked up in such a way that tooling/flags can control whether they are displayed? I'm imagining beginners (or their instructors) using some -ferror-messages=simple option to hide such suggestions.

goldfirere commented

I think one challenge here is that GHC is being called on to behave like an IDE, not just a batch compiler. In some sense, I would want its error messages to be raw output, where an IDE presents them in a suitably contextualized way. -ferror-messages=simple sounds tempting, but I'm afraid it would start us down a slippery slope to enable more and more flags to control error messages. I'm not hard against the idea, but I'm not excited by it at this point.

On the other hand, wording existing messages better is something relatively cheap and (quite possibly) effective.

  • 👍1
Ericson2314 commented

With structured errors, I think we should run wild about more structure that GHC the executable doesn't take advantage of as long as the IDE still does. Trying to make sure every library feature is exercised with a flag I think is just a waste of extra hoop-jumping --- better to unit test the GHC library if we want more test coverage instead.