-
-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implements :type [+v/+d]
in Eval Plugin
#361
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor changes requested, but otherwise looks good to me. Thank you!
I'm not sure I understand the issue with the current module. Is it the local default declarations, or the local pragmas, that are ignored? In any case, I don't see why either would be ignored. I would leave it as a known issue.
I note that these new commands (:kind
and :type
) involve very lightweight computation, and perhaps it would make sense to have a hover provider to show their evaluation.
src/Ide/Plugin/Eval.hs
Outdated
import Control.Arrow (Arrow(second)) | ||
import GHC (Ghc) | ||
import Type.Reflection (Typeable) | ||
import GHC (exprType) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's reorganise these imports please
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just pushed the commit that reorganises import list.
Anyway, is there any standard formatter and their configuration file in HLS, that could take care of import lists?
It seems ormolu doesn't reorganise import list.
Oops, sorry for the lack of explanation. It just ignores the |
Surely that also helps a lot! Since the type of the symbol under the pointer is already shown in hover, it might be helpful to provide |
It might be a good idea to add a test that shows the expected behaviour and tag it as "expected failure - known issue". |
@pepeiborra I've just added a test, which is deliberately ignored. Thanks for your suggestion! |
Why not |
It's just because I am not so familiar with |
This implements
:type
command ala GHCi.It also restructures the handling of GHCi-Like command and adds an exception for unknown command.
Examples
Known limitations
Currently,
:type +d
ignoresdefault
declarations specified in the module, though it can handledefault
s declared in the same>>>
prompt group.I once tried to obtain the module's defaulting declarations by applying
tcg_default
to thetm_internals_
ofTypecheckedModule
obtained byuse_ TypeCheck
andmappend
it to the HscEnv usingmodifySession
, but this doesn't change the situation.Is there any ideas to resolve this, or we can just let
+d
ignore the module's default pragma?For example, consider the following:
It is expected to say that
42 :: Int
. But with the current implementation, it answersInteger
,ignoring the module'sdefault
declaration:On the other hand, if we specify
default
inside the>>>
prompt, it works as expected: