Orthogonal; but would make sense as part of the same Big Bang Simon
From: Richard Eisenberg [mailto:[email protected]] Sent: 17 September 2012 15:25 To: Simon Peyton-Jones Cc: Niklas Broberg; [email protected] Subject: Re: Template Haskell and haskell-src-exts 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<http://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]<mailto:[email protected]> http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
