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