Re: Template Haskell and haskell-src-exts

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