Template Haskell changes to names and package keys

[Dan Burton]

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?

-- Dan Burton

On Fri, May 1, 2015 at 10:09 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> In GHC 7.10, we changed the internal representation of names to
> be based on package keys (base_XXXXXX) rather than package IDs
> (base-4.7.0.1), however, we forgot to update the Template Haskell
> API to track these changes.  This lead to some bugs in TH
> code which was synthesizing names by using package name and
> version directly, e.g. https://ghc.haskell.org/trac/ghc/ticket/10279
>
> We now propose the following changes to the TH API in order to
> track these changes:
>
>     1. Currently, a TH NameG contains a PkgName, defined as:
>
>         newtype PkgName = PkgName String
>
>        This is badly misleading, even in the old world order, since
>        these needed version numbers as well. We propose that this be
>        renamed to PkgKey:
>
>         newtype PkgKey = PkgKey String
>         mkPackageKey :: String -> PackageKey
>         mkPackageKey = PkgKey
>
>     2. Package keys are somewhat hard to synthesize, so we also
>        offer an API for querying the package database of the GHC which
>        is compiling your code for information about packages.  So,
>        we introduce a new abstract data type:
>
>         data Package
>         packageKey :: Package -> PkgKey
>
>        and some functions for getting packages:
>
>         searchPackage :: String -- Package name
>                       -> String -- Version
>                       -> Q [Package]
>
>         reifyPackage :: PkgKey -> Q Package
>
>        We could add other functions (e.g., return all packages with a
>        package name).
>
>     3. Commonly, a user wants to get the package key of the current
>        package.  Following Simon's suggestion, this will be done by
>        augmenting ModuleInfo:
>
>         data ModuleInfo =
>             ModuleInfo { mi_this_mod :: Module -- new
>                        , mi_imports :: [Module] }
>
>        We'll also add a function for accessing the module package key:
>
>         modulePackageKey :: Module -> PkgKey
>
>        And a convenience function for accessing the current module:
>
>         thisPackageKey :: Q PkgKey
>         thisPackageKey = fmap (modulePackageKey . mi_this_mod) qReifyModule
>
>         thisPackage :: Q Package
>         thisPackage = reifyPackage =<< thisPackageKey
>
> Discussion period: 1 month
>
> Thanks,
> Edward
>
> (apologies to cc'd folks, I sent from my wrong email address)
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150501/9d5d5bd8/attachment.html>