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