Open wdanilo opened 11 years ago
The main issue is library support. TH needs to use the same libraries as it's operating on, which means that (mainly) Haste's tuned integer-gmp
library causes vanilla GHC to barf on a bunch of unresolved externals. As far as I can tell, this is the only real obstacle (the changes to base
are small enough that conditional compilation would be quite enough there).
I'm going to look into fixing this, since it seems TH could be supported without too much hassle.
Has there been any progress here? I'm only making light use of TH (generating lenses from records) and it seems like that's all that's holding me back from full Haste compatibility on this project.
I was looking into using TH as well for client-side templating. Would love to see progress in this area.
I'd be really excited when/if something like Hamlet ends up working
Things like TH are very useful in webdev. Apart from templating, I would like to render parameterized yesod's routes to generate links in client-side code.
Aeson depends on template-haskell. So it would be really nice if Haste supports template-haskell.
It's big advantage of using on client and server same code for your domain model. But if Aeson library does not work(I also did not get it installed with haste-inst) , it just stops.... I can also look to another json library, but Aeson is most used. Also in other libraries.
+1
+1
+1
Hi! I want to ask you if you plan to support Template Haskell? As far as I understand it should be not big deal, because ghc can generate (in compile time) final pure Haskell code (out of mixed template code), so it should not theoretically change anything in your pipeline?