A comment on Introspective-Haskell
erkokl at gmail.com
Wed Dec 9 17:28:48 UTC 2015
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.
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:
>> 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?
>> ghc-devs mailing list
>> ghc-devs at haskell.org
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs