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

[ikervagyok]

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:

• Scoped type variables not suggested #6
  should recommend ScopedTypeVariables, since it's the obvious solution.
• Better suggestion for ambiguous type variables in certain situations #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]

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]

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.

[ikervagyok]

@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]

@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]

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?

[ikervagyok]

@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

[Ericson2314]

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!