Template Haskell changes to names and package keys

[Richard Eisenberg]

Thanks for spearheading this update.

I'm +1 on #1, in particular because I don't think TH should try too hard to have a stable API.

I'm +0.5 on #2, because the interface as designed below is too weak. I'm +1 for a stronger interface. For example:

packageVersionString :: Package -> String   -- maybe use a newtype here? or the proper Cabal datatype?
packageName          :: Package -> String   -- use the old PkgName here? or is that confusing?

packageDependencies :: Package -> Q [Package]
  -- could be very useful in printing debugging information. Then, if you're writing a library that
  -- is sensitive to dependency versions, you can print this info out when you panic

I'm -1 on #3 if it will break code. You can already get current package information through the `qLocation` function.

One need I've had a few times is to be able to get a version number for the current package, just for UI nicety. It would be great if this change could support such an operation (like my packageVersionString, above).

Thanks!
Richard

PS: I wonder if this proposal and debate wouldn't be easier to follow in wiki format. That way, the design could evolve over time...

On May 1, 2015, at 1:09 PM, 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