[GHC] #9946: Expose the source location of template-haskell Names

[GHC]

#9946: Expose the source location of template-haskell Names
-------------------------------------+-------------------------------------
        Reporter:  gridaphobe        |                   Owner:
            Type:  feature request   |                  Status:  new
        Priority:  low               |               Milestone:
       Component:  Compiler          |                 Version:  7.11
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by gridaphobe):

 Oh of course, I forgot about binding `Name`s inside the `Q` Monad.. That
 goes to show how much I actually use TH.

 I think we can break the `Name`s into three categories:

 1. Bound outside of TH (`NameL` and `NameS`):

    These are probably the easiest to handle, following my example
 [comment:3 above].

 2. Bound inside TH, uncapturable (`NameU`):

    This one also seems pretty straightforward since we know precisely
 where the `Name` was created, the call-site of `newName` (or `qNewName`).
 At the moment it's not easy to reflect that location to the running TH
 code, but the upcoming implicit-params call-stacks would work nicely here
 (I think). We'd change the types of `newName` and `qNewName` to
      {{{
      newName :: ?loc :: CallStack => String -> Q Name
      qNewName :: (?loc :: CallStack, Quasi m) => String -> m Name
      }}}
    I'm not convinced this location would ever actually be //useful//, but
 it's a sensible answer and I think we can generate it.
 3. Bound inside TH, capturable (`NameS` and `NameQ`):

    The desired behavior here would be to produce the `SrcLoc`
 corresponding to the definition of whatever `GHC.Name` the `TH.Name`
 resolves to, but I'm not sure how to do that yet. Somewhere inside GHC (I
 suspect wherever the splices are compiled and run) this dynamic resolution
 must be performed already. So //ideally//, we would just hook into that
 resolution process.

    This one seems by far the most difficult though.

 I'd also be open to returning a `Maybe SrcLoc`, which would only be
 defined in case (1), as that's good enough for my personal use. But it
 would sure be nicer to always return a sensible `SrcLoc`.

 EDIT: I just remembered that there's a function
 `CoreMonad.thNameToGhcName` that might be useful, though it might also
 attach an `UnhelpfulSrcSpan` to the `GHC.Name`. I'll experiment with it a
 bit and report back.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9946#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler