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
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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries