TemplateHaskell usage of Annotations

[Gergely Risko]

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 <simonpj at microsoft.com> 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 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