RE: Plugins: Accessing unexported bindings

gt; Cc: Eric Seidel <e...@seidel.io>; omeraga...@gmail.com; ezy...@mit.edu; ghc-devs@haskell.org Subject: Re: Plugins: Accessing unexported bindings Thanks for the explanation, Simon. I think Eric is spot on. Looking at some of the "ghc -v3" output, it appears GHC always runs the f

Re: Plugins: Accessing unexported bindings

aga...@gmail.com; ezy...@mit.edu; > ghc-devs@haskell.org > *Subject:* Re: Plugins: Accessing unexported bindings > > > > Thanks for the explanation, Simon. I think Eric is spot on. Looking at > some of the "ghc -v3" output, it appears GHC always runs the following &g

Re: Plugins: Accessing unexported bindings

ent: 07 December 2015 13:11 > To: Simon Peyton Jones <simo...@microsoft.com> > Cc: Eric Seidel <e...@seidel.io>; omeraga...@gmail.com; ezy...@mit.edu; > ghc-devs@haskell.org > Subject: Re: Plugins: Accessing unexported bindings > > That's a good point; keepi

RE: Plugins: Accessing unexported bindings

Simon Peyton Jones writes: > Plugins get to edit the entire core-to-core pipeline! There is no magic. At > least I don’t think so > > file:///Z:/tmp/users_guide/compiler-plugins.html > Or for those of us who aren't using Simon's desktop...

RE: Plugins: Accessing unexported bindings

gt;; omeraga...@gmail.com; | ezy...@mit.edu; ghc-devs@haskell.org | Subject: Re: Plugins: Accessing unexported bindings | | The problem, as I recall, is that GHC does an initial bit of dead-code | elimination in the desugarer, before the plugins have a chance to run. | (I believe

RE: Plugins: Accessing unexported bindings

ail.com; ezy...@mit.edu Cc: ghc-devs@haskell.org Subject: Re: Plugins: Accessing unexported bindings Omer, Eric, Ed: Thanks for the comments. Omer: I think Eric's observation is at play here. We're talking about "dead-code," i.e., a binding that is neither exported, nor used by any bindin

RE: Plugins: Accessing unexported bindings

vent Erkok [mailto:erk...@gmail.com] Sent: 07 December 2015 12:05 To: Simon Peyton Jones <simo...@microsoft.com> Cc: Eric Seidel <e...@seidel.io>; omeraga...@gmail.com; ezy...@mit.edu; ghc-devs@haskell.org Subject: Re: Plugins: Accessing unexported bindings Thanks Simon.. But I remain utterly

Re: Plugins: Accessing unexported bindings

ng their ExportFlag set, even though they are not exported > in the source-code sense. > > We should probably use a different term for ExportFlag, like > KeepAlive. > > From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Levent Erkok > Sent: 06 December 2015 20

Re: Plugins: Accessing unexported bindings

de? > > Simon > > From: Levent Erkok [mailto:erk...@gmail.com] > Sent: 07 December 2015 12:05 > To: Simon Peyton Jones <simo...@microsoft.com> > Cc: Eric Seidel <e...@seidel.io>; omeraga...@gmail.com; ezy...@mit.edu; > ghc-devs@haskell.org > Subject: Re: P

RE: Plugins: Accessing unexported bindings

..@gmail.com; ezy...@mit.edu; ghc-devs@haskell.org Subject: Re: Plugins: Accessing unexported bindings Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC should keep it alive. Is that something one of the core-developers can implement? Happy to open a ticket if that help

Re: Plugins: Accessing unexported bindings

.@seidel.io>; omeraga...@gmail.com; ezy...@mit.edu; > ghc-devs@haskell.org > Subject: Re: Plugins: Accessing unexported bindings > > Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC > should keep it alive. > > Is that something one of the core-d

RE: Plugins: Accessing unexported bindings

del <e...@seidel.io>; omeraga...@gmail.com; ezy...@mit.edu; ghc-devs@haskell.org Subject: Re: Plugins: Accessing unexported bindings That's a good point; keeping all annotated bindings alive seems to be an overkill.. Regarding implementing "pass at the start." I'm not sure if pl

Re: Plugins: Accessing unexported bindings

[mailto:e...@seidel.io] > | Sent: 07 December 2015 15:44 > | To: Simon Peyton Jones <simo...@microsoft.com> > | Cc: Levent Erkok <erk...@gmail.com>; omeraga...@gmail.com; > | ezy...@mit.edu; ghc-devs@haskell.org > | Subject: Re: Plugins: Accessing unexported bind

Re: Plugins: Accessing unexported bindings

If you have control over the Ids for the properties, if you can arrange for them to be marked "local exported" that should solve your problem. Edward Excerpts from Levent Erkok's message of 2015-12-05 23:01:29 -0800: > Hello, > > The mg_binds field of the ModGuts seem to only contain the

Re: Plugins: Accessing unexported bindings

2015-12-06 2:01 GMT-05:00 Levent Erkok : > The mg_binds field of the ModGuts seem to only contain the bindings that are > exported from the module being compiled. This is not true, it contains all the definitions in the module and I'm relying on this all the time. I just tested

Re: Plugins: Accessing unexported bindings

Omer, Eric, Ed: Thanks for the comments. Omer: I think Eric's observation is at play here. We're talking about "dead-code," i.e., a binding that is neither exported, nor used by any binding inside the module. Those seem to be getting dropped by the time user-plugins are run. Unfortunately, this

Re: Plugins: Accessing unexported bindings

GHC should only drop un-exported bindings from the ModGuts if they're also unused, ie *dead code*. The only way I know to get around this is to use the bindings somewhere, or just export them. On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote: > Hello, > > The mg_binds field of the ModGuts seem

Plugins: Accessing unexported bindings

Hello, The mg_binds field of the ModGuts seem to only contain the bindings that are exported from the module being compiled. I guess GHC must be running user-plugins after it drops the bindings that are not exported, which makes perfect sense for most use cases. However, I'm working on a plugin