Cafe, First let me say that Template Haskell is very powerful and a lot of great work has been done in this area. It fills in a number of holes in Haskell's feature set. But TH gives me the same feeling as other language features that have been described as "bolted on." Also, TH is both library and built-in syntax (via an extension) which feels strange to me. Finally, It's very complicated to do some simple things. I see TH used most for the following tasks: #1 Parse a string at compile-time so that a custom syntax for representing data can be used. At the extreme, this "data" might even be an EDSL. #2 Provide instances automatically. I would propose that more specialized features be implemented to accomplish these tasks. To start, I'll throw out some ideas that provide these capabilities. For TH use #1, compile-time parsing of arbitrary strings, I think it would be nice for quasiquote semantics to be modified so that code like
json :: String -> JsonObject json = ...
data = [ json | { "name" : "Jonathan" , "favorite language": "Haskell" } |]
causes the function json to be called at compile time with a string argument of " {\"name\" : \"Jonathan\"\n , \"favorite language\": \"Haskell\"\n }". The whole expression being then replaced with the result of the function application. What I like about this is that defining "quasiquoters" is trivial. They're just functions of the form String -> a. Many such quasiquoters already exist and would be ready for use! I imagine certain rules would apply, ie a quasiquoter must be defined prior to use and in a separate module, etc. For TH use #2, automatic instances, I would propose a way of declaring that a class can be automatically derived, and therefore added to the set [Eq, Ord, Show, Read, ... , etc]. This is the set of classes that can be put in the "deriving" clause of a type declaration. I don't know exactly what the syntax for this would look like, but I imagine it would look a bit like the various current implementations of automatic instances in TH. Again, TH is very powerful, and fills in a number of holes in Haskell's feature set. But it leaves me wondering if these holes should not be filled in by other, more specialized features, leaving TH to continue to find other holes to fill. I'm wondering if others see TH as a permanent solution, or if you agree with me that some of TH's most common usages should have more specialized features dedicated to them. It may very well be that I am simply not experienced enough with TH to fully appreciate and embrace it. By the way, did I miss any uses of TH as common as the ones I mentioned? --Jonathan