<div dir="ltr">Hi Luke!<div><br></div><div>I can tell you why I didn't want to include TH.</div><div><br></div><div>You are correct that TH does have many benefits and does indeed make a lot of things easier in Haskell. However, easier does not always mean more understandable. </div>

<div><br></div><div>Haskell has a pretty steep learning curve. Just learning the core Haskell98 is pretty difficult to grasp for a beginner. Adding TH haskell on top of that is bad news. There is an inherit disconnect between a template haskell function and the code it generates, because you can't see it. Type signatures in Haskell provide much more than hints to the compiler about types, they are also a good source of documentation. That is why I hate TH functions. Take for example Yesod's mkYesod type signature:</div>

<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font color="#000000" face="monospace"><span style="line-height:16.1200008392334px"><b>mkYesod :: String -> [Resource String] -> Q [Dec]</b></span></font></div>

<div><font color="#000000" face="monospace"><span style="line-height:16.1200008392334px"><b><br></b></span></font></div></blockquote><font color="#000000" face="arial, helvetica, sans-serif"><span style="line-height:16.1200008392334px">That doesn't give me any information about what to expect as a result. About the only way to know how to use this function is to find examples of it or start digging into the code. It would probably help some if it were standard practice for package maintainers to put the expected type-signatures along with the TH functions.</span></font><div>

<font color="#000000" face="arial, helvetica, sans-serif"><span style="line-height:16.1200008392334px"><br></span></font></div><div><div><font color="#000000" face="arial, helvetica, sans-serif"><span style="line-height:16.1200008392334px">Another problem that I see is that TH is not that discoverable. I would wager that most Haskell users know how to use Template Haskell functions but not how to implement them. TH is a sort of black box if you are beginner where you can't look at the source code for a TH function because once you look under the hood, it a bunch of VarTs, ConsTs, Decs.</span></font></div>
<div><br></div><div>--</div><div>Kyle Hanson</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 7, 2014 at 5:13 PM, Luke Clifton <span dir="ltr"><<a href="mailto:ltclifton@gmail.com" target="_blank">ltclifton@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
> I was rather frustrated with the use of Template Haskell as the main entry point for the big framework projects (Yesod, Snap, etc.)<br>
<br>
</div>Perhaps slightly off topic, but can someone outline why Template Haskell has so much negativity?<br>
<br>
I've used Yesod a bit, and from my limited experience, the TH does a good job at removing a lot of boilerplate code, while still keeping things readable and type safe.<br>
<br>
The main negatives I see are somewhat complicated error messages if you make a mistake, but the issue is usually pretty easy to spot because the TH is pretty simple.<br>
<br>
Is portability an issue? How do the other Haskell compilers go with it?<br>
<br>
Not to detract from your work, I think it's great to have options! I'm just curious.</blockquote></div><br></div>