Codelens: Not documented dependency on Prelude (NoImplicitPrelude EXT ON, causing it to output nothing)

[pe200012]

Your environment

Output of haskell-language-server --probe-tools or haskell-language-server-wrapper --probe-tools:

 I  ~/.c/C/U/g/haskell.haskell > ./haskell-language-server-wrapper-0.9.0-linux  --probe-tools                                 2021年02月05日 05時14分36秒
haskell-language-server version: 0.9.0.0 (GHC: 8.10.1) (PATH: /home/pe200012/.config/Code - Insiders/User/globalStorage/haskell.haskell/haskell-language-server-wrapper-0.9.0-linux) (GIT hash: 46d2a3dc7ef49ba57b2706022af1801149ab3f2b)
Tool versions found on the $PATH
cabal:          2.4.1.0
stack:          2.5.1
ghc:            Not found

Which lsp-client do you use: VS Haskell Extension

Describe your project (alternative: link to the project): https://github.com/pe200012/TAPL-Practice

Contents of hie.yaml:

cradle:
  stack:
    - path: "./src"
      component: "TAPL-Practice:lib"

    - path: "./app/Main.hs"
      component: "TAPL-Practice:exe:TAPL-Practice-exe"

    - path: "./app/Paths_TAPL_Practice.hs"
      component: "TAPL-Practice:exe:TAPL-Practice-exe"

    - path: "./test"
      component: "TAPL-Practice:test:TAPL-Practice-test"

Steps to reproduce

-- main.hs
{-# LANGUAGE NoImplicitPrelude #-}
module Main where

-- >>> 1

Expected behaviour

A plain "1" should appear under the evaluation statement when clicking Evaluate...

Actual behaviour

Nothing happens, even without an error message!

What I found

I found that you'd need these types imported from Prelude to make codelens available:

String,
Monad((>>=), (>>), return),
(.),  
Show(..),
IO

It's frustrating that there isn't even a single word talking about the dependency on it. It took about several hours for me to figure out the cause.

I wonder if you could add this information to the tutorial, which would help a lot when others encounter the same issue like me. Thanks in advance!

[Ailrun]

Thank you for the report. Yes, it looks like we need to update the document, and if possible, to print some messages saying that we uses those types/functions.

[konn]

I wonder if we could encapsulate helper functions used in Eval Plugin as another module and load it to avoid such complication with NoImplicitPrelude. I think rejection of 1 here is legitimate (yet some helpful comment must be printed definitely), as 1 will be desugared into fromInteger 1, where fromInteger lacks in the bare NoImplicitPrelude-only module. OTOH, I think pretty-printing feature must work independently of overrides introduced by NoImplicitPrelude, and can be packed as Prelude-dependent module (though some packages with nonstandard Prelude/base might need some care).

Just curious: why you used NoImplicitPrelude pragma without any imports, @pe200012? If you have imported the default or custom Prelude with enough symbols, there must be no errors, and without any imports but with NoImplicitPrelude pragma, it is hard to write meaningful programs, I think. And since Eval Plugin evaluates inputs in the current module context (this must be clarified in the doc, of course, thank you for pointing it out!), that's why evaluation fails.

[pe200012]

I wonder if we could encapsulate helper functions used in Eval Plugin as another module and load it to avoid such complication with NoImplicitPrelude. I think rejection of 1 here is legitimate (yet some helpful comment must be printed definitely), as 1 will be desugared into fromInteger 1, where fromInteger lacks in the bare NoImplicitPrelude-only module. OTOH, I think pretty-printing feature must work independently of overrides introduced by NoImplicitPrelude, and can be packed as Prelude-dependent module (though some packages with nonstandard Prelude/base might need some care).

Just curious: why you used NoImplicitPrelude pragma without any imports, @pe200012? If you have imported the default or custom Prelude with enough symbols, there must be no errors, and without any imports but with NoImplicitPrelude pragma, it is hard to write meaningful programs, I think. And since Eval Plugin evaluates inputs in the current module context (this must be clarified in the doc, of course, thank you for pointing it out!), that's why evaluation fails.

I happened to define many functions with the same name of these in Prelude, so I thought it might be better to turn on the NoImplicitPrelude extension and then manually import other functions I need (to avoid too many hiding (...) statements). Having never thinking about the issue it may bring to me :(

[jneira]

I wonder if we could encapsulate helper functions used in Eval Plugin as another module and load it to avoid such complication with NoImplicitPrelude. I think rejection of 1 here is legitimate (yet some helpful comment must be printed definitely), as 1 will be desugared into fromInteger 1, where fromInteger lacks in the bare NoImplicitPrelude-only module. OTOH, I think pretty-printing feature must work independently of overrides introduced by NoImplicitPrelude, and can be packed as Prelude-dependent module (though some packages with nonstandard Prelude/base might need some care).

I would try to fix the issue exploring that path and only document the need of those imports until we fix it

[konn]

I happened to define many functions with the same name of these in Prelude, so I thought it might be better to turn on the NoImplicitPrelude extension and then manually import other functions I need (to avoid too many hiding (...) statements). Having never thinking about the issue it may bring to me :(

I got it. I'm afraid that such usage is not intended one of NoImplicitPrelude: as stated in GHC User's Guide , its intended usage is to switch Prelude with its alternative and not to ease the burden to write many hiding clause, as it hides more things one might expect, including instance declarations.

As a side note: not released yet, but the master branch of HLS contains an import disambiguation functionality #1264; I hope this will help you in the near future, or you can build the master on your own 😃.

[jneira]

I'm afraid that such usage is not intended one of NoImplicitPrelude

Mmm, not sure about that, it is somewhat a corner case but imo it is a legitimate alternative if you want learn haskell reimplementing some of the prelude functions from absolute zero, only with basic language elements (to let clear what comes from one side or another)