On 19 October 2016 at 17:00, Simon Peyton Jones simonpj@microsoft.com wrote:

I’m afraid I didn’t understand the issue in the link below. It
speaks of “querying the type”, but I’m not sure what that means. A
GHCi session perhaps? Does this relate to the way GHCi displays
types?

I’m a bit lost. A from-the-beginning example, showing steps and
what the unexpected behaviour is would be helpful (to me anyway)

Sure. I’ll explain from top-level down:

So in summary we collect info from tm_typechecked_source, keep that
for later, and then when the user’s editor asks via e.g. :type-at X.hs 1 5 1 7 “what is the type of the thing at this point?” we use
GHC’s regular pretty printing function to print that type.

That actually all works splendidly. For example, if we query

foo g f = maybe g f
--  ^ here or   ^ here yields g :: b
foo g f = maybe g f
--    ^ here or   ^ here yields: f :: a -> b

The tricky part arises in this example:
https://github.com/commercialhaskell/intero/issues/280#issuecomment-254784904

Which is that we have two perfectly cromulent types from the AST that
are both a in isolation, but are actually different. They will have
different Unique values in their Name’s and come from different
implicit forall‘s. The question is what’s a good way to communicate
this to the user?

This is partly a “user interface” question, and on the side a “given
an ideal UI, do we have the necessary info the GHC API?”

If it helps, I could probably spend some time making an isolated
module that uses the GHC API to compile a file and then report these
types.

Ciao!