A comment on Introspective-Haskell

Richard Eisenberg eir at cis.upenn.edu
Fri Dec 11 22:23:23 UTC 2015


I'm seeing several different directions here, and it may be helpful to clarify what's going on:

* My original proposal was about changing the implementation of Template Haskell in a way that casual TH users wouldn't notice (by going through the compatibility shim). Once this is done, it may be possible to extend the idea to Core, but that wasn't my primary motivation.

* It seems that Levant wants Template Core. This idea is actually orthogonal from my original proposal, in that Template Core can be implemented with introspection or not. I think it will be easier with introspection, but it's just a matter of engineering either way.

* I don't think any real movement can be made on either of these issues without editing GHC itself. I don't see what a purely-external library could do.

* Yes yes yes, lots lots lots of pattern synonyms.

Does this clarify anything?

Richard

On Dec 9, 2015, at 12:28 PM, Levent Erkok <erkokl at gmail.com> wrote:

> Thomas: I honestly don't see why TH needs to go away. The way I viewed Richard's proposal was a means for me to get my hands on Core-splices inside my regular Haskell code. I think the two can co-exist happily. Perhaps others can opine on why we can't have both, aside from perhaps an argument about added complexity of having two different kinds of splices.
> 
> If there was an effort to allow Core-splices, I'd be happy to contribute so much as I can. Whether that ends up replacing TH or a compatibility shim is actually needed is a different question in my mind. That can be decided based on the experience with having Core-splices working first?
> 
> Please correct me if I'm wrong; in that TH and Core-splices cannot coexist, at least in theory, for some other reason.
> 
> -Levent.
> 
> On Wed, Dec 9, 2015 at 7:55 AM, Thomas Bereknyei <tomberek at gmail.com> wrote:
> This should be possible to start as a custom library. Appropriately shimming the result back into TH. Then with some experience and lessons learned we can investigate replacing TH with this new approach.
> 
> I ran across many similar issues with TH, haskell-src-exts, haskell-src-meta, etc.
> 
> Levent: Would it be appropriate for us to start putting together this shim? As Simon says in (https://ghc.haskell.org/trac/ghc/ticket/11081#comment:5) we can go a long ways with a plethora of pattern synonyms.
> 
> 
> On Tue, Dec 8, 2015 at 9:51 PM, Levent Erkok <erkokl at gmail.com> wrote:
> I just came across https://ghc.haskell.org/trac/ghc/ticket/11081, and the corresponding wiki-page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective
> 
> I think this is a terrific idea. In the past, I've tried both TH and haskell-src-exts to do relatively simple things, but ended-up abandoning them due to the inherent complexity of source level haskell that had very little to do with what I really cared about. Being able to get your hands on Core at the regular Haskell level would truly simplify life, and I suspect would open the flood-gates for a lot of people to develop extremely cool/useful artifacts, making the GHC/Haskell experience even better.
> 
> I hope this idea is taken further and sees the light-of-day.
> 
> Richard: Did you have any further thoughts about possible plans?
> 
> -Levent.
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/20cc1f3d/attachment-0001.html>


More information about the ghc-devs mailing list