
Dear all, (first, I don't know if this is the best place for questions/discussions about the GHC API, if not, let me know where to redirect the conversation). I've been writing a plugin that substitutes call to a function by calls to another (it's a plugin reimplementation of the assert feature of GHC). And to be able to point at the names of these two functions, I need to construct a name (well, and OccName) made of three parts: unit id, module name, definition name. This question is about the unit name. Currently I simply use stringToUnitId. But the real name of my unit has a magic string in it (see https://github.com/aspiwack/assert-plugin/blob/a538d72581bae43ebf44c332e19c5... ). It's rather unpleasant, it seems to change every time the cabal file change (at least). The assert-explainer plugin uses another approach, only using the module name, then calling findImportedModule ( https://github.com/ocharles/assert-explainer/blob/dc6ea213d4d0576954ec883eea... ). This is much more robust to changes, but is also less precise (technically, there can be several imported modules with the same name, with package-qualified imports). So, the question is: is there a better, recommended way to recover the OccName (or Name!) of a function I defined in the same unit my plugin is defined in. Best, Arnaud

Did you have a look at the implementation of `findImportedModule`? I
think you can use it and set the final argument to `Just
"assert-plugin"` so that it only looks for the module in the
`assert-plugin` package.
Another way people do this is to use a Template Haskell quote and then
use `GhcPlugins.thNameToGhcName`. Which is probably the most robust
way of persisting a name between the two stages.
Cheers,
Matt
On Fri, Feb 15, 2019 at 8:31 AM Spiwack, Arnaud
Dear all,
(first, I don't know if this is the best place for questions/discussions about the GHC API, if not, let me know where to redirect the conversation).
I've been writing a plugin that substitutes call to a function by calls to another (it's a plugin reimplementation of the assert feature of GHC). And to be able to point at the names of these two functions, I need to construct a name (well, and OccName) made of three parts: unit id, module name, definition name.
This question is about the unit name. Currently I simply use stringToUnitId. But the real name of my unit has a magic string in it (see https://github.com/aspiwack/assert-plugin/blob/a538d72581bae43ebf44c332e19c5... ). It's rather unpleasant, it seems to change every time the cabal file change (at least).
The assert-explainer plugin uses another approach, only using the module name, then calling findImportedModule ( https://github.com/ocharles/assert-explainer/blob/dc6ea213d4d0576954ec883eea... ).
This is much more robust to changes, but is also less precise (technically, there can be several imported modules with the same name, with package-qualified imports).
So, the question is: is there a better, recommended way to recover the OccName (or Name!) of a function I defined in the same unit my plugin is defined in.
Best, Arnaud _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Indeed, I missed the package-qualifer in findImportedModule. It does look plausible. If there is no recommended/better way to do this sort of thing, I think I'll go for it. If other plugin authors want to share their experience on what worked and didn't for them. I'd love to hear it, too. Seems like a common sort of problems in plugins. /Arnaud On Fri, Feb 15, 2019 at 9:41 AM Matthew Pickering < matthewtpickering@gmail.com> wrote:
Did you have a look at the implementation of `findImportedModule`? I think you can use it and set the final argument to `Just "assert-plugin"` so that it only looks for the module in the `assert-plugin` package.
Another way people do this is to use a Template Haskell quote and then use `GhcPlugins.thNameToGhcName`. Which is probably the most robust way of persisting a name between the two stages.
Cheers,
Matt
On Fri, Feb 15, 2019 at 8:31 AM Spiwack, Arnaud
wrote: Dear all,
(first, I don't know if this is the best place for questions/discussions
about the GHC API, if not, let me know where to redirect the conversation).
I've been writing a plugin that substitutes call to a function by calls
to another (it's a plugin reimplementation of the assert feature of GHC). And to be able to point at the names of these two functions, I need to construct a name (well, and OccName) made of three parts: unit id, module name, definition name.
This question is about the unit name. Currently I simply use
stringToUnitId. But the real name of my unit has a magic string in it (see https://github.com/aspiwack/assert-plugin/blob/a538d72581bae43ebf44c332e19c5... ). It's rather unpleasant, it seems to change every time the cabal file change (at least).
The assert-explainer plugin uses another approach, only using the module
name, then calling findImportedModule ( https://github.com/ocharles/assert-explainer/blob/dc6ea213d4d0576954ec883eea... ).
This is much more robust to changes, but is also less precise
(technically, there can be several imported modules with the same name, with package-qualified imports).
So, the question is: is there a better, recommended way to recover the
OccName (or Name!) of a function I defined in the same unit my plugin is defined in.
Best, Arnaud _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

I described another way to do it in the second paragraph of the email.
Does that not work?
Matt
On Mon, Feb 18, 2019 at 8:10 AM Spiwack, Arnaud
Indeed, I missed the package-qualifer in findImportedModule. It does look plausible. If there is no recommended/better way to do this sort of thing, I think I'll go for it.
If other plugin authors want to share their experience on what worked and didn't for them. I'd love to hear it, too. Seems like a common sort of problems in plugins.
/Arnaud
On Fri, Feb 15, 2019 at 9:41 AM Matthew Pickering
wrote: Did you have a look at the implementation of `findImportedModule`? I think you can use it and set the final argument to `Just "assert-plugin"` so that it only looks for the module in the `assert-plugin` package.
Another way people do this is to use a Template Haskell quote and then use `GhcPlugins.thNameToGhcName`. Which is probably the most robust way of persisting a name between the two stages.
Cheers,
Matt
On Fri, Feb 15, 2019 at 8:31 AM Spiwack, Arnaud
wrote: Dear all,
(first, I don't know if this is the best place for questions/discussions about the GHC API, if not, let me know where to redirect the conversation).
I've been writing a plugin that substitutes call to a function by calls to another (it's a plugin reimplementation of the assert feature of GHC). And to be able to point at the names of these two functions, I need to construct a name (well, and OccName) made of three parts: unit id, module name, definition name.
This question is about the unit name. Currently I simply use stringToUnitId. But the real name of my unit has a magic string in it (see https://github.com/aspiwack/assert-plugin/blob/a538d72581bae43ebf44c332e19c5... ). It's rather unpleasant, it seems to change every time the cabal file change (at least).
The assert-explainer plugin uses another approach, only using the module name, then calling findImportedModule ( https://github.com/ocharles/assert-explainer/blob/dc6ea213d4d0576954ec883eea... ).
This is much more robust to changes, but is also less precise (technically, there can be several imported modules with the same name, with package-qualified imports).
So, the question is: is there a better, recommended way to recover the OccName (or Name!) of a function I defined in the same unit my plugin is defined in.
Best, Arnaud _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

I described another way to do it in the second paragraph of the email. Does that not work?
It probably does. But it doesn't seem better since I don't have template haskell to begin with. So I'd intuitively go for the other findImportedModule method. Do you think I should rather use the Template Haskell method? If so why? I'm approaching this very naively: it's my first plugin, and I'm discovering all these things as I go. So I'm very curious as to what your opinion, and, more generally, the community's opinion is. /Arnaud

You only have to enable `TemplateHaskellQuotes` to use this. What's
your reason for not wanting to use Template Haskell?
Your general question is, how do I get a representation of this
Haskell identifier which I have in scope which I want to persist into
the future stage. The answer to this question of representation is to
use Template Haskell in general as that is precisely the role
of quotation.
Cheers,
Matt
On Mon, Feb 18, 2019 at 8:17 AM Spiwack, Arnaud
I described another way to do it in the second paragraph of the email. Does that not work?
It probably does. But it doesn't seem better since I don't have template haskell to begin with. So I'd intuitively go for the other findImportedModule method. Do you think I should rather use the Template Haskell method? If so why?
I'm approaching this very naively: it's my first plugin, and I'm discovering all these things as I go. So I'm very curious as to what your opinion, and, more generally, the community's opinion is.
/Arnaud

You only have to enable `TemplateHaskellQuotes` to use this. What's your reason for not wanting to use Template Haskell?
None, I just misunderstood your previous comment as meaning that it was useful for plugins taking some Template Haskell slice as an argument or something to that effect.
Your general question is, how do I get a representation of this Haskell identifier which I have in scope which I want to persist into the future stage. The answer to this question of representation is to use Template Haskell in general as that is precisely the role of quotation.
Got it. It does make sense. Thanks: I'll try this out. /Arnaud
participants (2)
-
Matthew Pickering
-
Spiwack, Arnaud