Getting a hole's relevant local binds?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Getting a hole's relevant local binds?

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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Getting a hole's relevant local binds?

Sandy Maguire
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 <[hidden email]> wrote:
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/

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Getting a hole's relevant local binds?

Matthew Pickering
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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> 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/
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Getting a hole's relevant local binds?

GHC - devs mailing list
In reply to this post by Sandy Maguire

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 <[hidden email]> On Behalf Of Sandy Maguire
Sent: 18 August 2019 01:28
To: [hidden email]
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/


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Getting a hole's relevant local binds?

Sandy Maguire
In reply to this post by Matthew Pickering
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> 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/
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> 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/

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Getting a hole's relevant local binds?

Sandy Maguire
In reply to this post by GHC - devs mailing list
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Sandy Maguire
Sent: 18 August 2019 01:28
To: [hidden email]
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/

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Getting a hole's relevant local binds?

GHC - devs mailing list

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>    = <do something with expr of interest, knowing all in-scope binding s in env>

 

Simon

 

 

From: Sandy Maguire <[hidden email]>
Sent: 29 August 2019 06:37
To: Simon Peyton Jones <[hidden email]>
Cc: Sandy Maguire <[hidden email]>; [hidden email]
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Sandy Maguire
Sent: 18 August 2019 01:28
To: [hidden email]
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/


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Getting a hole's relevant local binds?

Sandy Maguire
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 <[hidden email]> 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>    = <do something with expr of interest, knowing all in-scope binding s in env>

 

Simon

 

 

From: Sandy Maguire <[hidden email]>
Sent: 29 August 2019 06:37
To: Simon Peyton Jones <[hidden email]>
Cc: Sandy Maguire <[hidden email]>; [hidden email]
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Sandy Maguire
Sent: 18 August 2019 01:28
To: [hidden email]
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/



--
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs