Getting a hole's relevant local binds?
Simon Peyton Jones
simonpj at microsoft.com
Wed Aug 28 11:56:15 UTC 2019
how receptive would y'all be to a patch that puts the `TcLclEnv`, or something similar inside `XUnboundVar GhcTc`.
That sounds plausible. But is an unbound-var the only place an editor/IDE tooling might want to get its hands on such a thing? ie would that solve your problem, but not the next person’s?
Also note that you could easily build up a list of all the in-scope Ids simply by gathering them from the tree as you walk inwards. There’s no actual need for a new function -- although I can see it might be more convenient.
From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Sandy Maguire
Sent: 18 August 2019 01:28
To: ghc-devs at haskell.org
Subject: Getting a hole's relevant local binds?
I'm trying to get my hands on the relevant local binds (as reported by ghc in the presence of a type hole) for editor tooling support. Tracing the code suggests that these things come from the `TcLclEnv`, but afaict, all remnants of `TcLclEnv` are thrown away by the time we get a `TypecheckedModule`.
Am I mistaken in this? If not, how receptive would y'all be to a patch that puts the `TcLclEnv`, or something similar inside `XUnboundVar GhcTc`. This way editors would have an easy means of getting their hand on whatever is in scope at the site of a hole, without resorting to parsing error messages.
I'm currently traveling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs