This page describes a way to "join up" the
haskell-src-exts library with Template Haskell, to avoid senseless duplication of effort.
It’s stupid, stupid to have both the large
Language.Haskell.TH data types for Haskell (in the
template-haskell package) and the large
Language.Haskell.Exts data types for Haskell (in the
- The duplication does not serve our users well. Sometimes they even need to grapple with BOTH data types in the same probram, and We even have a package that converts from one to the other!
- The duplication does not serve use as developers well. We are duplicating some pretty serious effort on data type design, pretty printer, analysis, etc etc.
The proposal is simple: we re-build the
template-haskell library to sit on top of
haskell-src-exts, using all the latter's data types to represent Haskell syntax. We would do this in collaboration with Niklas Broberg, the author of
There are a few bits in the TH data type that specifically support Template Haskell, including
Namtype (reconciliation needed here)
Qmonad and result types for reify (no equivalent in
I think we can solve all this with some negotiation, but I guess it is just possible that there is some major technical obstacle.
- The massive question is the disruptive effect on existing TH users. Changing all the data types will be a Real Pain for them. But the long term benefits seem quite compelling. We’d need to make a clear blog post/email etc to advertise and seek feedback.
One possibility is to support BOTH for a while (deprecating the existing data types). Perhaps by having two package (old and new). Initially “old” is deprecated but is the package you get by default. But “new” is available, and the same GHC can deal with its data types. I think this would be possible, with some work.