TemplateHaskell usage of Annotations

[Simon Peyton-Jones]

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 at 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