Re: Getting a hole's relevant local binds?

Fair enough --- though it's annoying that GHC can offer me exactly the information I want in an error message, but then force me to duplicate the logic to find those things for myself! On Thu, Aug 29, 2019 at 12:20 AM Simon Peyton Jones wrote:

Simon, my reasoning here is that holes are the only place GHC will mention relevant bindings. I'd definitely prefer to put all of the relevant local bindings in scope for _every_ HsVar, but that seemed less amenable to being merged :)

I didn’t explain myself well enough. No need to merge anything. *Your tooling* can accumulate these bindings as it walks the tree -- no need for GHC to do anything. Eg

myTooling env (HsLam (HsVar x) e) = myTooling (extend env x) e

myTooling env <expr of interest> =

Simon

*From:* Sandy Maguire *Sent:* 29 August 2019 06:37 *To:* Simon Peyton Jones *Cc:* Sandy Maguire ; ghc-devs@haskell.org *Subject:* Re: Getting a hole's relevant local binds?

Simon, my reasoning here is that holes are the only place GHC will mention relevant bindings. I'd definitely prefer to put all of the relevant local bindings in scope for _every_ HsVar, but that seemed less amenable to being merged :)

On Wed, Aug 28, 2019 at 4:56 AM Simon Peyton Jones wrote:

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.

Simon

*From:* ghc-devs *On Behalf Of *Sandy Maguire *Sent:* 18 August 2019 01:28 *To:* ghc-devs@haskell.org *Subject:* Getting a hole's relevant local binds?

Hi all,

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.

Cheers,

Sandy

--

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/ https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fisovector.github.io%2Ferdos%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cd7c51847a19c4d6aa84208d72c42e32b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637026538110642901&sdata=UClCONCXwkap3HhQ5hZroULJ67uy08UsndYgsrIcvxg%3D&reserved=0

--

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/ https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fisovector.github.io%2Ferdos%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cd7c51847a19c4d6aa84208d72c42e32b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637026538110652887&sdata=koBEz03JagWpN7NeS9qbBWqpUK5psZoGoz7fwQxgGp8%3D&reserved=0

-- 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/