Template Haskell changes to names and package keys

Michael Sloan mgsloan at gmail.com
Fri May 1 23:12:30 UTC 2015

+1 on #2 and #3.

Being able to get all the packages that have a particular name sounds
good!  Note that if "-hide-package" / "-hide-all-packages" is used, I
wouldn't want those packages in the results.

Considering that we also have the Module / ModuleInfo datatypes, to me it
makes sense that we'd also be able to get a [Module] from a Package.

Like Dan, I'm a little less keen on #1.  Here's why:

* PkgName is in the internal "Language.Haskell.TH.Syntax" module

* It isn't actually documented what it means, so it's meaning can be freely
bent.  There's no guarantee that you should be able to generate them.

* I couldn't find any examples of its usage that would be broken by this
new semantics.  I've done a search on github[1] to find usages of PkgName,
and I only found one use[2] that uses PkgName which would be affected by
this change.  This example is in the TH lib itself, and so would hopefully
be fixed by this change.

On the other hand, since it's rarely used, such an API breakage wouldn't be
that impactful, so it's not that big of a deal.


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-, 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/998602bf/attachment.html>

More information about the Libraries mailing list