Wouldn't that make haskell-src-exts a boot package? I think that would mean that users could upgrade haskell-src-exts independently, but won't be able to use the upgraded version and TH in the same program. Or am I missing something?
On 15 September 2012 09:32, Simon Peyton-Jones <[email protected]>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**** > > **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 > > -- Push the envelope. Watch it bend.
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
