:type/:type-at follow up tasks

[gracjan]

When #598 is done there are things that should be improved in that scope:

• find out it if haskell-mode-show-type-at, haskell-process-do-type and haskell-process-do-try-type can be merged into one functionality
• if it cannot be merged select a nice binding key
• document the binding key
• handle situation when :set +c was not executed by detecting "Couldn't guess that module name. Does it exist?", see here https://github.com/chrisdone/ghci-ng/blob/d5c4e41e265d3f35c976185f0eaa283e05e78169/ghc/GhciFind.hs#L39
• handle situation when :type-at is a syntax error because somebody uses plain GHCi instead of GHCI-ng: unknown command ':type-at', inform user
• handle when inserting a signature but selection is only a part of expression, for example selecting from p to 'i' in map (+1) list. Currently it inserts something in the middle breaking the program completely.

[geraldus]

@gracjan "Couldn't guess that module name. Does it exist?" it also happens if you have not loaded file, e.g. even if you have :set +c option enabled running :type-at will give this error until you load target file (in Emacs you need C-c C-l first, or :load in REPL). I think we can provide nice message, something like this:

Could not infer type signature, have loaded file? If so, check that +c option is enabled.

As for :type-at we definitely should point to GHCi-ng README.

First task in my todo list already. I'll have a look a bit lately.

As for the last task: this is known behaviour, and it is a bit confusing for me. For example I can't imagine what could make user to infer type for a part of expression, like error in error404 or read in readMay or more confusing examples like pi and etc. in middle of expression. Looks like in all these cases we should not insert type signature. So, when region active we need to make some checks about surrounding of region. But it could be a bit complicated: for example we could insert type for region containing a b in expression a b=, but don't for a b in a b.c. So, I need some help with clarifying this stuff.

[geraldus]

I think we could merge haskell-process-do-type and haskell-process-insert-type, both use same command :type (…), also insert-type functionality likely missing.
https://github.com/haskell/haskell-mode/blob/master/haskell-commands.el#L312
https://github.com/haskell/haskell-mode/blob/master/haskell-commands.el#L379

[geraldus]

Differences between haskell-process-do-type and haskell-process-do-try-type, …-do-info and …-do-try-info:

• do-type and do-info grab identifier at point or expression within active region, while do-try-type takes literal expression as argument
• do-type optionally could insert result
• do-info optionally prompts user for identifier
• do-try-… functions show result only if there was good response, e.g. REPL does not reported error; and they always use haskell-mode-message-line, which effectively truncates all useful information from long responses most of the time.

Likely, these are essentially equal functions. I suppose we could merge this functions.
In case of type functions we need:

• an option to specify identifier rather than grabbing it (also interactively)
• an option to insert result (ignored when insert-result option selected)
• an option not to show errors

In case of info functions:

• an option to specify identifier rather than grabbing it (also interactively)
• an option not to show errors

Present results same way as haskell-process-show-type-at does (using presentation mode if enabled).
Rename haskell-process-show-type-at to haskell-process-do-type-at and add option not to show errors in sake of consistency.

[gracjan]

I'm still thinking about this one. There is a lot of room for improvement here.

[gracjan]

I did some more research. This is what ghc-mod does:

• ghc-show-info
• ghc-show-type

Are there people loving ghc-mod way?

[PierreR]

Are there people loving ghc-mod way?

Yes. When it works (ghc-mod is kind of fragile), I find it much more useful than haskell-process-do-type.

Mostly because the later requires haskell-process which is generally clumsy (I don't want to sound too negative but I have yet to see someone using it in a screencast, I have been trying to use haskell-process multiple times and always gave up to fire an external ghci session).

Then, let say haskell-process would work nicely, it doesn't seem to expand the type on multiple press. ghc-show-type does it and it is really useful.

[geraldus]

expand the type on multiple press

Can you explain a bit?

[PierreR]

Can you explain a bit?

For instance given the expression error "hello". If the cursor is on the word error, I press c-c c-t and I have got the type String -> IO() with the word error highlight. If I press c-c c-t again, I have got the whole expression highlighted with the type IO().

It works for more complex expressions. This feature does not seem to exist with haskell-process-do-type which makes it a less interesting option.

[geraldus]

I was not aware of such behavior, but I think it's not hard to implement. @gracjan what do you think about this stuff?

But this is minor issue, as for me the the major issue is about merging -do- and -do-try- functions.
Other minor issue is presentation mode support, and haskell-mode-message-line (which truncates inferred type signatures).
@gracjan can you please mark tasks that already have been done?

Oh, by the way, @PierreR can you please tell me does ghc-mod work for identifiers inside local let and where blocks?

[gracjan]

There is a function called mark-sexp described in #648.

Repeated C-c C-t could be a mixture of extending sexp marked plus get type info.

Anyway we need to have proper semantics described in #648 before we can put more functionality under C-c C-t.

[PierreR]

Oh, by the way, @PierreR can you please tell me does ghc-mod work for identifiers inside local let and where blocks?

@geraldus Yes c-c c-t works fine in where blocks and local let.

[geraldus]

@PierreR, thanks, now we now that ghc-mod type inference could be replaced only with …-show-type-at (GHCi-ng feature), but not …-do-type