[Haskell-cafe] Template Haskell a Permanent solution?

[Jonas Almström Duregård]

Hi,

> 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.

I don't understand why the library/extension duality is a problem. I would
say that the best approach is to have language support (through extensions)
for primitive operations like splicing, and to have libraries that combine
these operations into more complex systems (like automatic derivation of
type classes).

> 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.

Shouldn't specialized features be defined in terms of general features?

>> json :: String -> JsonObject
>> json = ...
>>
>> data = [ json |
>>    { "name" : "Jonathan"
>>    , "favorite language": "Haskell"
>>    }
>>|]

How does this differ from the current QuasiQuotes extension? From what I can
tell, all you need to achieve this with TH is to automatically derive a
Language.Haskell.TH.Lift instance for JsonObject, i.e. a  function lift ::
JsonObject -> Q Exp such that the expression will evaluate to the original
JsonObject. A QuasiQuoter like the one you describe can then be created by
QuasiQuoter { parseExp = lift . json }. Should both approaches be supported
directly, or should we sacrifice the generality of the current quoters for
the simplicity of the ones you suggest?


The second part (deriving instances for general type classes) is a lot more
complicated. I would say that the most general way of showing that a class
can be derived is to provide a function that produces a set of declarations
given the name of the datatype. Here's a very simple suggestion for
incorporating this into the Haskell deriving syntax. Suppose we have these
two classes and TH functions for deriving them:

class Class1 ...
class Class2 ...

class1 :: Name -> Q [Dec]
class2 :: Name -> Q [Dec]

data D = D deriving (Show,class1,class2)

The last declaration could expand to:

data D = D deriving Show
class1 'D
class2 'D

If you don't want to write class1 and class2 by operating directly on
Haskell declarations, but rather use some DSL for specifying instances, then
all you need is a function deriv :: DerivationDSL -> (Name -> Q [Dec]).

/J

On 27 December 2010 08:35, Jonathan Geddes <geddes.jonathan at gmail.com>
wrote:
> 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
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20101227/72f1fa28/attachment-0001.htm>