Type query from up to date file information

[dudebout]

When I use the function haskell-process-do-type (C-c C-t) I often get the answer "Top level: Not in scope: foo'". This is because the query made byhaskell-modeuses the current content loaded inghci` and not the content of the file.

Is there a reason why the call to haskell-process-do-type does not reload the content of the file in ghci before querying it?

The same question applies to haskell-process-do-info (C-c C-i).

[chrisdone]

There's no particular reason. It could send an import, or optionally a reload, before doing that. I wouldn't personally have it on by default, but it could be an option.

[dudebout]

I am curious why you would not have this on by default? For efficiency reason? If so, would a "reload-if-newer" approach be more desirable?

[chrisdone]

Possibly, yeah. GHCi is a bit finicky.

[hvr]

Well, here's one reason for not wanting this always: sometimes you're in the middle of editing your code when you want to check the type, and the code wouldn't type-check/parse yet properly...

[dudebout]

What would then be the expected type returned by such a check?

[hvr]

Probably the last state during editing for which the code still made sense to the compiler... but we'd need incremental compiler support for this to become practical imho, as you can't trigger a save-buffer + reload in GHCi for each character you type... (+ reverting to previous state if :reload fails)

[dudebout]

I believe that the query should be in sync with what is shown in the buffer. Anything else is confusing. If I have to keep in mind what state is in ghci it will lead to some confusion.

I would rather see with flycheck that the code does not parse and have C-c C-t fail rather than it returning an incorrect type.

[hvr]

I believe that the query should be in sync with what is shown in the buffer. Anything else is confusing.

Btw, you're contradicting yourself a little bit here. In the original issue description, you wanted the query to be based on the current file-contents, and now you're arguing for using the current buffer-contents instead...

[dudebout]

All I am saying is that it should reflect what the programmer sees and not what ghci last saw. Either the content of the buffer or the file is fine. If it is the file, I will have emacs save right before I do the query.

[hvr]

If it is the file, I will have emacs save right before I do the query.

...if you're prepared to type a C-x C-s before you C-c C-{t,i}, what's keeping you from typing C-c C-l (*) before C-c C-{t,i}? ;-)

(*) which currently saves the buffer as a side-effect w/o asking -- which should be made customizable anyway

PS: don't get me wrong, like @chrisdone, I'm not against this feature, I just don't want it on by default

[chrisdone]

I got the point. It sounds do-able, but if you know Elisp I can point you where you can start with the inferior process if you want. You'll need some ingredients:

• Make a variable that stores the last module that was loaded and when.
• When using one of the load commands, if the module succeeds at loading, put it in the variable with the current time.
• When running type info, check whether the module is in that variable and whether the modified time of the file is greater than the variable (an edited unsaved file is similar). If it's changed, just queue a :load before-hand.

One risk you have is losing type information—if the current module doesn't type-check—that you would've had otherwise. But that's a trade-off with what GHCi provides.

If you don't know Elisp (learn it!), you can leave this ticket open, perhaps someone will add it. Like @hvr says, it's not saving you many key presses.

[chrisdone]

One risk you have is losing type information—if the current module doesn't type-check—that you would've had otherwise. But that's a trade-off with what GHCi provides.

Afterthought: I read your update posts and see that you'd prefer no type than a possibly-wrong type. Fair enough.

[dudebout]

@hvr I will have emacs save means that I will add a hook. I am not going to type it ;-)

@chrisdone thanks for the pointers. My main goal with opening this issue was to figure out if there was any reason for the behavior I observed. I will give it a shot.

What I am trying to do is get a neat functionality from ghc-mod which is M-t. You type it on a line lacking a type binding and it will add it appropriately without having to load or save. Very handy!

[chrisdone]

Check out haskell-process-queue-command and the functions for loading and getting types. The commands sent to the process work in an asynchronous (commands don't block) queue, and are run one-by-one in sequence. Feel free to ask any questions in here.

Getting type info a la ghc-mod will be difficult because GHCi gives very limited inspection capabilities.

[dudebout]

So far I seemed to get the same result with haskell-mode and ghc-mod. Do you have any example in mind where ghc-mod would give an answer but not ghci?

[chrisdone]

Sub-expressions? When the file's invalid?

[hvr]

@chrisdone are you sure ghc-mod type is able to work on invalid Haskell source files?

[dudebout]

@hvr I just checked. You cannot.

[gracjan]

This issue report was last update in 2013. Is it still relevant to current code state?

[chrisdone]

hvr commented on 17 Jul 2013

Sub-expressions? When the file's invalid?
@chrisdone are you sure ghc-mod type is able to work on invalid Haskell source files?

I meant the reverse. GHCi gives you (old) info when the file is invalid. I think ghc-mod does not because it requests type info on-demand.

gracjan commented an hour ago

This issue report was last update in 2013. Is it still relevant to current code state?

Yup.

[gracjan]

It seems that HIE will provide this functionality. I do not see this happening in haskell-mode due to lack of resources.