How does this relate to http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal ?
I seem to recall seeing an email/post/something recently indicating that the plan on the wiki page was currently being implemented. Thanks, Richard On Sep 15, 2012, at 4:32 AM, Simon Peyton-Jones wrote: > Niklas > > Yesterday we discussed the possibility of merging your haskell-src-exts and > the template-haskell library, as part of your vision for a Haskell Suite. > > Motivation. It’s stupid, stupid to have both the large Language.Haskell.TH > data types for Haskell and the largeLanguage.Haskell.Exts data types for > Haskell. > · 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. > > Proposal. > · We merge the two > · You remain the primary maintainer > · The new package (however we name it) completely replaces the > existing template-haskell package. > All this relies on a clear sense that you, and other friends who help with > haskell-src-exts, will continue to love, maintain, and develop it. Of > course, there is a virtuous cycle here: sustaining that energy will become > easier if it was central to Template Haskell. But I would NOT want people to > feel “Oh, now haskell-src-exts is part of GHC, so we don’t need to continue > to love and maintain it”. > > Issues > · There are a few bits in the TH data type that specifically support > Template Haskell, including > o The Name type (reconciliation needed here) > o The Q monad and result types for reify (no equivalent in haskell-src-exts) > 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. > > · Who will do the work? (There will be quite a bit!) I think you > sounded willing consider taking the lead, though of course you will want to > think more about it before making a commitment. For my part I am definitely > willing to discuss details, and would want to be involved in the design > decisions, but I can’t commit to doing Serious Work. So this only makes > sense if, upon reflection, you and whatever friends you can persuade to join > you, are willing to take the lion’s share of the work. > > best wishes > > Simon > _______________________________________________ > Cvs-ghc mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
