Template Haskell changes to names and package keys

[Edward Z. Yang]

Hello Dan,

https://ghc.haskell.org/trac/ghc/ticket/9265 I think summarizes
the reason why we shifted to this.  It's also important infrastructural
groundwork for a more sophisticated module system in Haskell.

Edward

Excerpts from Dan Burton's message of 2015-05-01 11:54:05 -0700:
> 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
> >