Thanks for the review. I've validated and agree with your observation regarding the usages issue. To my current understanding, the current patch always reifies too much, never too less. Since we don't have a lot of time before 7.8.1, I'd like to use your offer to apply #1480 as-is and I will continue fixing the remaining issues subsequently. Thanks a lot for being lenient on this! Gergely On Wed, 30 Oct 2013 09:05:48 +0000, Simon Peyton-Jones writes:

Thanks. I have reviewed once more.

* http://ghc.haskell.org/trac/ghc/ticket/1480 * http://ghc.haskell.org/trac/ghc/ticket/8397

On #1480 I know that you are desperate to get it into 7.8.1. Austin, if Gergely wants I am ok with committing #1480 as-is, and fixing it properly subsequently.

Simon

| -----Original Message----- | From: Gergely Risko [mailto:gergely@risko.hu] | Sent: 22 October 2013 17:32 | To: Simon Peyton-Jones | Subject: Re: TemplateHaskell usage of Annotations | | The following message is a courtesy copy of an article | that has been posted to gmane.comp.lang.haskell.ghc.devel as well. | | Hi, | | Here is a status report on how things are going at the moment on the | TemplateHaskell+Annotations issue. | | Further discussion happened with Austin and Simon: | - http://ghc.haskell.org/trac/ghc/ticket/8397, | - http://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Annotations | | SPJ asked for moving the discussion to ghc-devs from tickets, so I'm | replying to this comment already here: | | > It would be better to conduct this conversation on ghc-devs but I | > don't know your email address, and I don't know if you are on | > ghc-devs, so I'll continue here. Maybe you can reply on ghc-devs. | > | > Thanks for the wiki page. I've had a look. What's missing is the | > actual design proposal itself! I have made some minor edits, leaving a | > blank section for you to fill in. Think of it from the point of view | > of a programmer... what do they need to know? Perhaps show how the new | > API lets you implement the stuff you want. | | Good point, there were no clear example or API overview on the page, I | filled in the blanks. Thanks for the review. | | > As to details of #1480, I'm really not sure that we need both | > qReifyImports and qReifyModule. Can't we just use qReifyModule to get | > the imports of the current module? | | Yes, you're right, I changed the patches in #1480 to get rid of | qReifyImports. The only way I found to get the name of the current | module is via qLocation, so I added a helper function to TH/Lib.hs, | named thisModule. It's then easy to use it together with reifyModule as | shown the worked out example. | | There is one info lost with this approach though: when we're reifying | imports from the current module, we also have the local names (I mean | Bar in "import Foo as Bar"). That info may be useful for the guys in | http://ghc.haskell.org/trac/ghc/ticket/1444, but I'm not sure. | | We naturally not have that info for modules loaded from interface files, | and we'd never need that anyway; no point in generating local names for | an already compiled and finished module. | | Despite this info loss, I think your approach is still better: it's | simpler and my solution is a bit premature, it doesn't solve #1444 in | itself, just adds to the confusion. We can add it back anyways if we | decide so later. | | Gergely