Re: A comment on Introspective-Haskell

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 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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs