Re: Template Haskell and haskell-src-exts

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
>