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 <[email protected]> Sent: 29 August 2019 06:37 To: Simon Peyton Jones <[email protected]> Cc: Sandy Maguire <[email protected]>; [email protected] 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> On Behalf Of Sandy Maguire Sent: 18 August 2019 01:28 To: [email protected]<mailto:[email protected]> 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>
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
