I wasn't aware of hole fit plugins! Though I'm not sure they're particularly useful for tooling outside of GHC; it's not clear how I'd install a plugin and then get results out of it into a completely different process. Furthermore, do they only give me hole _fits_? I also need to get my hands on zonked bindings in scope. On Thu, Aug 22, 2019 at 9:40 AM Matthew Pickering < matthewtpickering@gmail.com> wrote:

Are you aware of hole fit plugins Sandy? Do they provide a nice API for you to use?

This sounds like a cool and simple change anyway. What happens if you add this additional information using a source plugin or is that too late?

Matt

On Thu, Aug 22, 2019 at 5:24 PM Sandy Maguire wrote:

...

Following up on this, I've hacked in the changes locally, by setting

`XVar GhcTc = [Name, Type]`, and filling it only for `HsVar`s that used to be `HsUnboundVar`s. The result is remarkable, as it allows for interactive proof search. I've got a proof of concept here: https://asciinema.org/a/FZjEIFzDoHBv741QDHfsU5cn8

...

I think the possibilities here warrant making the same change in HEAD.

I'd be happy to send an MR if it seems likely to be merged.

...

Sandy

On Sat, Aug 17, 2019 at 6:27 PM Sandy Maguire

...

...

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

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

-- 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/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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/

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

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/