Hello all, I was rather frustrated with the use of Template Haskell as the main entry point for the big framework projects (Yesod, Snap, etc.) While these frameworks offer template-free options, they seem like second class citizens. So I started work on Wheb with the goal that out of the box I could start a project quickly, without Template Haskell and without the dreaded long list of Language Pragma's at the top. I was inspired by the simplicity of the Scotty project which showed how easy a Haskell server could be to write. I have included a couple of plugin examples for handling Auth and Sessions. Wheb is database and template agnostic, but I plan to write some plugins soon to make it easier to use the major libraries with Wheb. I just started work on it last weekend but wanted to share my progress. Take a look if it interests you! http://hackage.haskell.org/package/Wheb-0.0.1.1 https://github.com/hansonkd/Wheb-Framework Thanks, Kyle Hanson
I was rather frustrated with the use of Template Haskell as the main entry point for the big framework projects (Yesod, Snap, etc.)
Perhaps slightly off topic, but can someone outline why Template Haskell has so much negativity? 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. 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. Is portability an issue? How do the other Haskell compilers go with it? Not to detract from your work, I think it's great to have options! I'm just curious.
The main disadvantage of TH for me is that it's not amenable to static
analysis or reasoning. Because the meaning of a TH splice is in no way
related to its type, it both breaks tools, and breaks my patterns of
understanding how things work by navigating the consistent generated
documentation on Hackage.
There are also portability concerns. Not with non-GHC compilers (no one
uses anything but GHC), but with cross-compiling and such, including
projects like GHCJS (last time I checked anyway).
On Feb 7, 2014 5:14 PM, "Luke Clifton"
I was rather frustrated with the use of Template Haskell as the main entry point for the big framework projects (Yesod, Snap, etc.)
Perhaps slightly off topic, but can someone outline why Template Haskell has so much negativity?
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.
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.
Is portability an issue? How do the other Haskell compilers go with it?
Not to detract from your work, I think it's great to have options! I'm just curious. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Hi Luke!
I can tell you why I didn't want to include TH.
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.
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:
*mkYesod :: String -> [Resource String] -> Q [Dec]*
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.
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.
--
Kyle Hanson
On Fri, Feb 7, 2014 at 5:13 PM, Luke Clifton
I was rather frustrated with the use of Template Haskell as the main entry point for the big framework projects (Yesod, Snap, etc.)
Perhaps slightly off topic, but can someone outline why Template Haskell has so much negativity?
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.
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.
Is portability an issue? How do the other Haskell compilers go with it?
Not to detract from your work, I think it's great to have options! I'm just curious.
Haskell is itself quite good at removing boilerplate code. In fact, we Haskellers sometimes take pride in writing clean and boilerplate-free code. Forcing us to use metaprogramming undermines our pride. That's why Template Haskell is much more disliked than other forms of metaprogramming — CPP, C++ templates, Lisp macros, Tcl, Forth, etc. It essentially boils down to this: Template Haskell is hated because Haskell itself is so damn good. Of course, if you have a shitty language to start with, then metaprogramming can only be seen as great help.
Personally, I'm opposed to any form of metaprogramming. I prefer simplicity (says the guy who once asked SPJ if we're going to have polymorphic kinds), so I like having abstractions that semantically lie in the problem domain. Metaprogramming constructs, by definition, have their semantics defined in terms of the code they generate. I don't want to think about code. Ideally, I'd prefer not to see any code, but that's not on the plate right now. That's why I don't like metaprogramming, except for C++ templates, they have some sort of beautiful ugliness.
On 08 Feb 2014, at 05:13, Luke Clifton
I was rather frustrated with the use of Template Haskell as the main entry point for the big framework projects (Yesod, Snap, etc.)
Perhaps slightly off topic, but can someone outline why Template Haskell has so much negativity?
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.
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.
Is portability an issue? How do the other Haskell compilers go with it?
Not to detract from your work, I think it's great to have options! I'm just curious. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Kyle,
have you tried Happstack? It doesn't need Template Haskell, or a long list of pragmas, and it doesn't care what template or database engine you use.
It's main disadvantage is that it's not WAI, which seems to be ideologically superior; I've heard (or imagined) that there were some plans to make it WAI.
On 07 Feb 2014, at 22:07, Kyle Hanson
Hello all,
I was rather frustrated with the use of Template Haskell as the main entry point for the big framework projects (Yesod, Snap, etc.) While these frameworks offer template-free options, they seem like second class citizens. So I started work on Wheb with the goal that out of the box I could start a project quickly, without Template Haskell and without the dreaded long list of Language Pragma's at the top. I was inspired by the simplicity of the Scotty project which showed how easy a Haskell server could be to write.
I have included a couple of plugin examples for handling Auth and Sessions. Wheb is database and template agnostic, but I plan to write some plugins soon to make it easier to use the major libraries with Wheb.
I just started work on it last weekend but wanted to share my progress. Take a look if it interests you!
http://hackage.haskell.org/package/Wheb-0.0.1.1
https://github.com/hansonkd/Wheb-Framework
Thanks, Kyle Hanson _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (4)
-
Chris Smith -
Kyle Hanson -
Luke Clifton -
MigMit