TemplateHaskell usage of Annotations

[Gergely Risko]

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