haskell/error-messages

Language Extensions vs. Plain Haskell 98/2010/...

Opened this issue · 7 comments

ikervagyok commented

After reading the first few issues, I think it would be nice if there were guidelines on when to recommend enabling language extensions in the error messages.

e.g.: I think the examples in #6 and #7 should be handled differently:

  • #6
    should recommend ScopedTypeVariables, since it's the obvious solution.
  • #7
    should only recommend TypeApplications if it is already enabled and stick to type signatures otherwise, since it doesn't need the extension.

wdyt?

noughtmare commented

I think the problem in #7 is that it is possible to fix it without type applications and in fact that should be preferred in my opinion, but it is much harder (perhaps impossible in general) for the compiler to provide an automated suggested fix without the extension, because the place where you should add a type signature is not the place where the error occurs.

goldfirere commented

I agree that general guidelines about enabling extensions would be good.... maybe in the form of a set of language extensions that are recommended all the time and others that are only conditionally recommended. The particular issue mentioned here -- around TypeApplications -- may actually be moot, as TypeApplications is on by default in GHC 9.2+: see https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst.

  • 👍3
ikervagyok commented

@goldfirere This comment is based on your latest video: https://youtu.be/Qy_yxVkO8no?t=520

GHC shouldn't recommend something that will still break the next round of compiling:
e.g.: Plain Haskell -> MultiParamTypeClasses -> FunctionalDependencies

enabling the recommended Language extension should fix the reported problem.

tomjaguarpaw commented

@ikervagyok Do you mean it should recommend MultiParamTypeClasses and FunctionalDependencies the first time? If so then I agrees strongly. I come across examples like this frequently (generally MultiParamTypeClasses and FlexibleContexts).

goldfirere commented

In this case, FunctionalDependencies implies MultiParamTypeClasses, so recommending FD is functionally the same as recommending FD+MPTC.

Yes, I agree. This one small thing is a nice separable piece. Maybe it's ready to produce a GHC ticket?

  • 🎉1
ikervagyok commented

@tomjaguarpaw I don't have an opinion on whether GHC should in these kind of cases recommend all extensions explicitly or just the deduplicated list, as long as GHC's suggestion leads to compiling code in a single recompile round (at least in trivial cases like this).

@goldfirere I opened a ticket for this at https://gitlab.haskell.org/ghc/ghc/-/issues/20177

  • 🎉1
Ericson2314 commented

I, as a more advanced user, might want to provide my own whitelist of extensions that are allowed to be suggested, or even so whitelist everything with a wildcard.

For example, I had a parse error on pattern Foo in an export list the other day, and was completely baffled by the error for like a solid minute until I realized I must have removed the {-# LANGUAGE PatternSynnoyms #-} at some point.

I would have rather I got the "did you mean to enabled pattern synoyms?" from the get-go, so I could fix it and move on before my concentration faltered!