Eval plugin reports "Ambiguous type variable" where ghci does not.

[fmehta]

Which lsp-client do you use:
VS Code

Steps to reproduce

Type -- >>> head []in the editor and click on Evaluate...

Expected behaviour

Output:
*** Exception: Prelude.head: empty list
as in ghci.

Actual behaviour

Output:

-- Ambiguous type variable ‘f0’ 
-- prevents the constraint ‘(Show f0)’ from being solved.
-- Probable fix: use a type annotation to specify what ‘f0’ should be.
-- These potential instances exist:
--   instance Show a => Show (ZipList a)
--     -- Defined in ‘Control.Applicative’
--   instance Show NestedAtomically
--     -- Defined in ‘Control.Exception.Base’
--   instance Show NoMethodError -- Defined in ‘Control.Exception.Base’
--   ...plus 215 others
--   (use -fprint-potential-instances to see them all)

Workaround

Specifying a concrete type, such as -- >>> head ([]::[Int]) does not result in this error, but is not pretty.

[berberman]

GHCi enables ExtendedDefaultRules by default, so head [] can be type-checked. You could enable this language extension to get the similar behaviour. It wouldn't be hard to let eval plugin enable this by default as well, so PRs are welcome!

[July541]

I built the master branch without ExtendedDefaultRelus, but -- >>> head [] print *** Exception: Prelude.head: empty list correctly as we often met. I checked the log file and found nothing different between the official version and my own build.

Reproduce procedure:

1. run cabal build
2. copy from dist-newstyle executable file path to VSCode setting file Haskell: Server Executable Path

[berberman]

Actually, head [] in ghci can be typechecked without ExtendedDefaultRelus. It's kind of subtle -- in this case, the type of head [] is unified to IO a, resulting in a new interactive binding, instead of printing an expression. Thus, there is no Show constraint need to be satisfied, where no "ambiguous type variable" occurs.

#1603 made eval plugin behave like ghci, so it works in master now, but didn't work as this issue was created. However, ExtendedDefaultRelus is still important in other cases, and we'd better change the example of this issue to reverse [].

[Ailrun]

Simpler case requires ExtendedDefaultRules:

-- >>> []