From: Antoine Latter

Sent: Sunday, October 2, 2011 9:21 PM

On Sun, Oct 2, 2011 at 8:31 PM, Brandon Moore wrote: ...

...

If the package isn't meant to be upgraded, should it be on hackage at all?

Using an install of the template-haskell library other than the one GHC was built against will make GHC unhappy - the operations in the library won't type-check against the built-in GHC magic.

If so, the package should not be on hackage with dependencies that lead cabal-install to try to upgrade it. I see three ways to fix this   1) Remove template-haskell from the package index (perhaps keeping       the documentation somehow)   2) Strengthen the dependencies enough to force the GHC version   3) Fix cabal-install to avoid the package. I don't understand the situation well enough yet, but #1 sounds good if the package is just on hackage for documentation links, and the set of libraries tied to a specific compiler is the same for past ghc versions and other compillers. Brandon

From: Ivan Lazar Miljenovic

...

I see two possible reasons for having it (along with other boot libraries) still on Hackage:

1) An archive of previous versions

Archiving the packages is good, and especially making to documentation available for other packages to link into. It seems this would still be covered if everything else was left how it is, but the .cabal file for the packages were removed from the package index in 00-index.tgz. Having found http://hackage.haskell.org/trac/hackage/wiki/HackageDB I'll see whether that's as easily done as said.

2) In case some other compiler one day supports TH.

I don't know of any concrete projects along those lines, so this doesn't seem to argue for anything beyond point 1). I suppose another project probably would want to share the template haskell source, but I expect it would end up being part of their equivalent of boot libraries. Brandon