Template Haskell changes to names and package keys

[Dan Burton]

Thanks Edward.

#3 looks like an obvious win.

#1 looks like harmless bikeshedding. (Keep the old mkPkgName and pkgString
and `type PkgName = PkgKey` as synonyms for a deprecation cycle or two?).

As for #2, searchPackage struck me as odd at first. What could a TH user do
with a list of packages that are all "the same version"? As specified, it's
rather opaque. However, it occurs to me that if the Package data type has
some information about, for example, the [Package] that it was built
against, then perhaps some useful things could be done via TH with this
information.

So upon second look, it seems to me that the proposed points are really not
all that complex. +1 from me, fwiw

-- Dan Burton

On Fri, May 1, 2015 at 1:08 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> 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
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150501/4d2abaf4/attachment.html>