In principle this sounds good. I just thought I'd mention
http://hackage.haskell.org/trac/ghc/ticket/3355 which is related, though not directly. Cheers, Simon On 15/09/2012 09:32, 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 *large* Language.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 oThe Name type (reconciliation needed here) oThe 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
