
Dear Simon, other ghc devs, I hooked into genericHscRecompile to traverse the typechecked source and construct an environment of type [(SrcSpan, Id)] recording all identifiers in the source with their type, definition site, etc. To be precise, I am traversing the tcg_binds :: LHsBinds Id, -- Value bindings in this module field of the TcGblEnv structure returned by the type checker. The problem is that I have so far been unable to find top-level user-supplied type annotations inside LHsBinds. The closest thing I've found is the PostTcType of a MatchGroup, but that is not Located; what I'm really looking for is an LSig. Now, let-bindings get a HsValBindsLR instead of an LHsBinds, and that *does* contain signatures. My question is two-fold: 1. First, am I missing something? Are there LSigs somewhere inside the TcGblEnv where I simply haven't seen them? 2. If not, is there a good reason why tcg_binds is an LHsBinds rather than an HsValBindsLR? And if there isn't, would you accept a patch making the change? Thanks, Edsko

On 18/02/13 14:02, Edsko de Vries wrote:
Dear Simon, other ghc devs,
I hooked into genericHscRecompile to traverse the typechecked source and construct an environment of type
[(SrcSpan, Id)]
recording all identifiers in the source with their type, definition site, etc. To be precise, I am traversing the
tcg_binds :: LHsBinds Id, -- Value bindings in this module
field of the TcGblEnv structure returned by the type checker. The problem is that I have so far been unable to find top-level user-supplied type annotations inside LHsBinds. The closest thing I've found is the PostTcType of a MatchGroup, but that is not Located; what I'm really looking for is an LSig. Now, let-bindings get a HsValBindsLR instead of an LHsBinds, and that *does* contain signatures. My question is two-fold:
1. First, am I missing something? Are there LSigs somewhere inside the TcGblEnv where I simply haven't seen them?
This might not be directly answering your question, but there are quite a few things that are not in the output of the typechecker, type signatures being one of them. There's a little list in GHC.hs which I paste below for your enjoyment: -- - the export list -- - the imports -- - type signatures -- - type/data/newtype declarations -- - class declarations -- - instances I vaguely remember having some discussions in the past about having the typechecker run over the renamed versions of these replacing Names with Ids, but I don't think it ever got implemented. So the best you can do right now is use the renamed versions of these, and you get Names rather than Ids. Cheers, Simon
2. If not, is there a good reason why tcg_binds is an LHsBinds rather than an HsValBindsLR? And if there isn't, would you accept a patch making the change?
Thanks,
Edsko
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Can't you just use the range of the tcg_type_env? Simon From: Edsko de Vries [mailto:edskodevries@gmail.com] Sent: 18 February 2013 14:03 To: Simon Peyton-Jones Cc: ghc-devs@haskell.org Subject: Top-level type signatures in TcGblEnv? Dear Simon, other ghc devs, I hooked into genericHscRecompile to traverse the typechecked source and construct an environment of type [(SrcSpan, Id)] recording all identifiers in the source with their type, definition site, etc. To be precise, I am traversing the tcg_binds :: LHsBinds Id, -- Value bindings in this module field of the TcGblEnv structure returned by the type checker. The problem is that I have so far been unable to find top-level user-supplied type annotations inside LHsBinds. The closest thing I've found is the PostTcType of a MatchGroup, but that is not Located; what I'm really looking for is an LSig. Now, let-bindings get a HsValBindsLR instead of an LHsBinds, and that *does* contain signatures. My question is two-fold: 1. First, am I missing something? Are there LSigs somewhere inside the TcGblEnv where I simply haven't seen them? 2. If not, is there a good reason why tcg_binds is an LHsBinds rather than an HsValBindsLR? And if there isn't, would you accept a patch making the change? Thanks, Edsko

I'm sorry, I don't see any location information ("Located .." types) in
tcg_type_env?
Edsko
On Mon, Feb 25, 2013 at 3:22 PM, Simon Peyton-Jones
Can’t you just use the range of the tcg_type_env?
Simon****
** **
*From:* Edsko de Vries [mailto:edskodevries@gmail.com] *Sent:* 18 February 2013 14:03 *To:* Simon Peyton-Jones *Cc:* ghc-devs@haskell.org *Subject:* Top-level type signatures in TcGblEnv?****
** **
Dear Simon, other ghc devs,****
** **
I hooked into genericHscRecompile to traverse the typechecked source and construct an environment of type****
** **
[(SrcSpan, Id)]****
** **
recording all identifiers in the source with their type, definition site, etc. To be precise, I am traversing the ****
** **
tcg_binds :: LHsBinds Id, -- Value bindings in this module****
** **
field of the TcGblEnv structure returned by the type checker. The problem is that I have so far been unable to find top-level user-supplied type annotations inside LHsBinds. The closest thing I've found is the PostTcType of a MatchGroup, but that is not Located; what I'm really looking for is an LSig. ****
** **
Now, let-bindings get a HsValBindsLR instead of an LHsBinds, and that *does* contain signatures. My question is two-fold:****
** **
1. First, am I missing something? Are there LSigs somewhere inside the TcGblEnv where I simply haven't seen them?****
** **
2. If not, is there a good reason why tcg_binds is an LHsBinds rather than an HsValBindsLR? And if there isn't, would you accept a patch making the change?****
** **
Thanks,****
** **
Edsko****

The SrcSpan of the binding site is stored inside the Id. getSrcSpan should do it.
S
From: Edsko de Vries [mailto:edskodevries@gmail.com]
Sent: 25 February 2013 16:27
To: Simon Peyton-Jones
Cc: ghc-devs@haskell.org
Subject: Re: Top-level type signatures in TcGblEnv?
I'm sorry, I don't see any location information ("Located .." types) in tcg_type_env?
Edsko
On Mon, Feb 25, 2013 at 3:22 PM, Simon Peyton-Jones

Ah, yes. But I am interested in the SrcSpan of the *usage site* (as well as
the binding site).
Edsko
On Mon, Feb 25, 2013 at 4:41 PM, Simon Peyton-Jones
The SrcSpan of the binding site is stored inside the Id. getSrcSpan should do it.****
** **
S****
** **
*From:* Edsko de Vries [mailto:edskodevries@gmail.com] *Sent:* 25 February 2013 16:27
*To:* Simon Peyton-Jones *Cc:* ghc-devs@haskell.org *Subject:* Re: Top-level type signatures in TcGblEnv?****
** **
I'm sorry, I don't see any location information ("Located .." types) in tcg_type_env?****
** **
Edsko****
** **
On Mon, Feb 25, 2013 at 3:22 PM, Simon Peyton-Jones
wrote:**** Can’t you just use the range of the tcg_type_env?
Simon****
****
*From:* Edsko de Vries [mailto:edskodevries@gmail.com] *Sent:* 18 February 2013 14:03 *To:* Simon Peyton-Jones *Cc:* ghc-devs@haskell.org *Subject:* Top-level type signatures in TcGblEnv?****
****
Dear Simon, other ghc devs,****
****
I hooked into genericHscRecompile to traverse the typechecked source and construct an environment of type****
****
[(SrcSpan, Id)]****
****
recording all identifiers in the source with their type, definition site, etc. To be precise, I am traversing the ****
****
tcg_binds :: LHsBinds Id, -- Value bindings in this module****
****
field of the TcGblEnv structure returned by the type checker. The problem is that I have so far been unable to find top-level user-supplied type annotations inside LHsBinds. The closest thing I've found is the PostTcType of a MatchGroup, but that is not Located; what I'm really looking for is an LSig. ****
****
Now, let-bindings get a HsValBindsLR instead of an LHsBinds, and that *does* contain signatures. My question is two-fold:****
****
1. First, am I missing something? Are there LSigs somewhere inside the TcGblEnv where I simply haven't seen them?****
****
2. If not, is there a good reason why tcg_binds is an LHsBinds rather than an HsValBindsLR? And if there isn't, would you accept a patch making the change?****
****
Thanks,****
****
Edsko****
** **
participants (3)
-
Edsko de Vries
-
Simon Marlow
-
Simon Peyton-Jones