Expose the source location of template-haskell Names

I've often wanted to know where a particular Name is defined (specifically the filepath), but as far as I can tell, template-haskell doesn't currently support this. It'd be really nice to have a function

nameLoc :: Name -> Loc

to expose the definition site of the Name.

I think this should be fairly straightforward to add since GHC carries the definition site around with its Names, but I've never looked at the TH internals.

Trac metadata

Trac field	Value
Version	7.11
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	low
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 3

added Tfeature request Trac import labels

What is the specification? Exactly what location would you expect to get? Examples would be a good start.

Spec: Add a single function

nameSrcLoc :: TH.Name -> GHC.SrcLoc.SrcLoc

using the upcoming SrcLoc type from D578, which returns the span of the whole definition, e.g.

module A where

head :: [a] -> a
head [] = undefined
head (x:_) = x

module B where

loc = nameLoc 'A.head
  -- loc == A.hs:3:1-5:15

This provides maximal information, and my intuition is that it might be easier for clients to narrow the span (e.g. to the first equation) if needed than to widen it.

But, as above, I've only ever needed the filepath in practice, so I'm very open to convincing that a different span would be more useful.

Actually, including the type signature doesn't seem feasible (or at least useful), given that

foo :: Int -> Int
bar :: Int -> Int

foo = ...
bar = ...

is perfectly valid. So let me amend my example [ticket:9946#comment:94982 above] to

loc = nameLoc 'A.head
  -- loc == A.hs:4:1-5:15

An example is good, and I encouraged you to start with examples. But ultimately we need a complete specification that says what happens for every Name.

There are lots of ways to generate a Name in TH, and you only give one. How about

f :: Q Exp -> Q Exp
f qe = do { Var x <- qe
          ; print (nameLoc x)
          ; [| blah |] }

For example I might call f with f [| x |], or f [| \x -> x |].

Or you can use newName or mkName to create a Name.

What locations would they have?

Look at data Name and NameFlavour in Language.Haskell.TH. I guess that you might reasonably expect a location for a NameG and perhaps a NameL. But it's not clear that nameLoc :: Name -> Maybe SrcLoc will be useful to you.

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

I think we can break the Names into three categories:

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

These are probably the easiest to handle, following my example [ticket:9946#comment:94986 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.

1. 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.~~ This doesn't actually make any sense as the TH.Name would already have a SrcLoc attached under my proposal.

There is, unfortunately, a subcase in (1) that I forgot above, namely wired-in Names. We can't ever hope to produce a useful SrcLoc from nameSrcLoc '[].

This is another good argument to return a Maybe SrcLoc.

added Plow label