<div dir="ltr">Can you give (or link to) the rationale for the internal representation change? What use cases (or new corner cases for ghc-7.10) justify the added complexity here?</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">-- Dan Burton</div></div>
<br><div class="gmail_quote">On Fri, May 1, 2015 at 10:09 AM, Edward Z. Yang <span dir="ltr"><<a href="mailto:ezyang@mit.edu" target="_blank">ezyang@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In GHC 7.10, we changed the internal representation of names to<br>
be based on package keys (base_XXXXXX) rather than package IDs<br>
(base-4.7.0.1), however, we forgot to update the Template Haskell<br>
API to track these changes.  This lead to some bugs in TH<br>
code which was synthesizing names by using package name and<br>
version directly, e.g. <a href="https://ghc.haskell.org/trac/ghc/ticket/10279" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/10279</a><br>
<br>
We now propose the following changes to the TH API in order to<br>
track these changes:<br>
<br>
    1. Currently, a TH NameG contains a PkgName, defined as:<br>
<br>
        newtype PkgName = PkgName String<br>
<br>
       This is badly misleading, even in the old world order, since<br>
       these needed version numbers as well. We propose that this be<br>
       renamed to PkgKey:<br>
<br>
        newtype PkgKey = PkgKey String<br>
        mkPackageKey :: String -> PackageKey<br>
        mkPackageKey = PkgKey<br>
<br>
    2. Package keys are somewhat hard to synthesize, so we also<br>
       offer an API for querying the package database of the GHC which<br>
       is compiling your code for information about packages.  So,<br>
       we introduce a new abstract data type:<br>
<br>
        data Package<br>
        packageKey :: Package -> PkgKey<br>
<br>
       and some functions for getting packages:<br>
<br>
        searchPackage :: String -- Package name<br>
                      -> String -- Version<br>
                      -> Q [Package]<br>
<br>
        reifyPackage :: PkgKey -> Q Package<br>
<br>
       We could add other functions (e.g., return all packages with a<br>
       package name).<br>
<br>
    3. Commonly, a user wants to get the package key of the current<br>
       package.  Following Simon's suggestion, this will be done by<br>
       augmenting ModuleInfo:<br>
<br>
        data ModuleInfo =<br>
            ModuleInfo { mi_this_mod :: Module -- new<br>
                       , mi_imports :: [Module] }<br>
<br>
       We'll also add a function for accessing the module package key:<br>
<br>
        modulePackageKey :: Module -> PkgKey<br>
<br>
       And a convenience function for accessing the current module:<br>
<br>
        thisPackageKey :: Q PkgKey<br>
        thisPackageKey = fmap (modulePackageKey . mi_this_mod) qReifyModule<br>
<br>
        thisPackage :: Q Package<br>
        thisPackage = reifyPackage =<< thisPackageKey<br>
<br>
Discussion period: 1 month<br>
<br>
Thanks,<br>
Edward<br>
<br>
(apologies to cc'd folks, I sent from my wrong email address)<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div><br></div>