Template Haskell changes to names and package keys

[Simon Peyton Jones]

Why do we need two types: PkgKey and Package?   Can't we make them the same?

It's good that Package be abstract (as proposed below). Then we are free to add more metadata to it

I'd urge that Module too should be abstract, for the same reason


Simon


|  -----Original Message-----
|  From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of
|  Edward Z. Yang
|  Sent: 01 May 2015 18:09
|  To: libraries
|  Subject: Template Haskell changes to names and package keys
|  
|  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