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