Template Haskell changes to names and package keys

[Edward Z. Yang]

> I didn't search for that, since I was searching for explicit uses of
> PkgName.  The results for NameG are pretty interesting, though:
> 
> https://github.com/search?l=haskell&q=NameG&type=Code&utf8=%E2%9C%93
> 
> It seems like most of the results are either `Lift`ing a PkgName or
> re-using a PkgName from another name.  However, there are a fair number of
> uses which explicitly construct the name, though.  In particular, there are
> a fair number of usages of this to generate references to the tuple
> constructors in GHC.Prim.
> 
> Interestingly, these usages of (mkPkgName "ghc-prim") don't have version
> numbers at all.  This implies that the behavior is to select the version of
> the package which is currently being used.

Well, the reason they don't have version numbers is because ghc-prim
(and a few other packages) are internally considered wired-in packages,
so their package keys are always some specific, hard-coded value.
There is no "implied behavior", it's just an implementation detail that
this TH API happens to expose.  (There is one concrete consequence of
this, which is that it's not possible to have two versions of ghc-prim
simultaneously in the same executable.)

Prior to 7.10, this manifested as ghc-prim having PkgName
"ghc-prim", but lens having PkgName "lens-0.3.2".

> So, how about for this rare-ish case where there we're linking against two
> different versions of the foo package, and the TH manually generates a
> (PkgName "foo"), we generate an ambiguity error.
> 
> If we force users to search for and specify fully unambiguous package names
> then that pushes the boilerplate of package selection out to TH usage.  It
> seems like pretty much everyone will want "select the version of the
> package that I'm using."  That said, I'm also in favor of adding the
> function mentioned in #2, for those cases where the default isn't
> sufficient (I'm anticipating very few of these).

I looked at the results.

    https://github.com/bitemyapp/hackage-packages/blob/fd9649f426254c0581bd976789a1c384eda0e3c9/lighttpd-conf-0.4/src/Lighttpd/Conf/Instances/Lift.hs
    This is just very wrong, they should clearly switch to thisPackageKey when we have it

    https://github.com/s9gf4ult/letqq/blob/472d665cf64ec60b5f02f200c2b4c54fc6580f3f/src/THTH.hs
    I'm not really sure what this is supposed to be, besides some
    meta-meta-programming library. It's clearly prototype code and I
    don't think they will mind if it stops working.

    https://github.com/suhailshergill/liboleg/blob/57673d01c66ab9f284579a40aed059ed4617ce6c/Data/Symbolic/TypedCodeAux.hs
    https://github.com/bitemyapp/hackage-packages/blob/fd9649f426254c0581bd976789a1c384eda0e3c9/liboleg-2010.1.10.0/Data/Symbolic/TypedCodeAux.hs
    So, this piece of code is something that really ought to be in the
    standard library, if it isn't already.  Basically, the problem is
    that when you quote an identifier, e.g. [| foo |], you get the
    *un-renamed* syntax (a variable foo) rather than the renamed syntax
    (somepkg:Data.Foo.foo).  This is very useful, too useful to be in
    another library.

    https://github.com/andrep/hoc/blob/bfd0391bf0dab4bda5d6a5f7845fab19f8e4b9a9/hoc/HOC/HOC/TH.hs
    https://github.com/mokus0/hoc/blob/b6fa3906b8e1e61bed0435a8d497a132e5905227/hoc/HOC/HOC/TH.hs
    Wouldn't be broken.

    https://github.com/DavidAlphaFox/ghc/blob/6a5d9fa147b8abc370159d87e9c3dac87171cbd5/libraries/template-haskell/Language/Haskell/TH/Quote.hs
    This (and the next page of results) are from the template-haskell
    library. We can fix these ourselves when we make these changes.

To sum up, I still think we should rename, and I think we should
also add some functionality to the standard library for getting the
renamed version of a TH syntax tree.

Edward