[Haskell-cafe] Template Haskell a Permanent solution?

[Jonathan Geddes]

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