---------- Forwarded message ---------- From: Vyacheslav Akhmechet <coffeemug@gmail.com> Date: Aug 24, 2006 5:35 PM Subject: Re: Data.Generics vs. Template Haskell To: Bulat Ziganshin <Bulat.Ziganshin@gmail.com> Ok, so there are two aspects that I can see here. One such aspect is ability to "reflect" on types (at runtime or compile time). An example of that is creating an automatic mapping from relational databases to haskell newtypes. Another aspect is being able to get an a representation of Haskell code AST in terms of Haskell datatypes in order to be able to process Haskell ASTs in Haskell. As far as I can see the first aspect is a subset of the second because all Haskell types are known at compile time. If this is the case, why the need for two libraries (I am not counting DriFT because it looks like it hasn't been maintained for a long time)? Or am I missing something? Additionally, which one is more maintained and has the most potential to become standard (whether de facto or real) in the future? On 8/24/06, Bulat Ziganshin <bulat.ziganshin@gmail.com> wrote:

Hello Vyacheslav,

Thursday, August 24, 2006, 11:51:46 PM, you wrote:

...

I am trying to figure out where these two libraries stand in relation to each other and which one is preferred to do generic programming in Haskell. I understand that their goals often intersect but couldn't find any good comparisons. Could someone point me in the right direction?

search for "generics" on hswiki, you should find a lot of papers. in particular, there is a new paper that compares many different approaches to generic programming. in particular, TH is not g.p. tools, it's just a universal Haskell code generator whcih can be used to solve particular tasks in this area. but to solve general problem of defining traversal function what has some general case and a nu,ber of type-specific cases TH is not very appropriate

TH (and DriFT) are widely used to generate instances like the haskell compiler itself generates instances for Eq/Show/... and TH, unlike many g.p. tools does it at compile-time. using TH, you also get access to field/constructor names

summary: if your task fits into the features provided by g.p. tools, you will gain a much time using them. if your task need compile-time code generation (so that generic program will be no slower than hand-written one) or you need some advanced features which your g.p. tool doesn't provide - welcome to TH with all its programming oddities. development of TH routines for g.p. is an order of magnitude slower (at least!) than doing the same with specialized tool

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com