[Haskell-cafe] Re: could we get a Data instance for Data.Text.Text?

[Neil Mitchell]

Hi,

The problem with Data for Text isn't that we have to write a new
instance, but that you could argue that proper handling of Text with
Data would not be using a type class, but have special knowledge baked
in to Data. That's far worse than the Serialise problem mentioned
above, and no one other than the Data authors could solve it. Of
course, I don't believe that, but it is a possible interpretation.

The Serialise problem is a serious one. I can't think of any good
solutions, but I recommend you give knowledge of your serialise class
to Derive (http://community.haskell.org/~ndm/derive/) and then at
least the instances can be auto-generated. Writing lots of boilerplate
and regularly ripping it up is annoying, setting up something to
generate it for you reduces the pain.

>> The only safe rule is: if you don't control the class, C, or you don't
>> control the type constructor, T, don't make instance C T.
>
> I agree in principle, but in the real world you can't live by this rule.
> Example, I want to use Uniplate to traverse the tree built by haskell-src-exts,
> Using Data.Data is too slow, so I need to make my own instances.
> HSE provides like 50 types that need instances, and it has to be
> exactly those types.
> Also, Uniplate requires instances of a particular class it has.

Read my recent blog post
(http://neilmitchell.blogspot.com/2010/01/optimising-hlint.html), I
optimised Uniplate for working with HSE on top of the Data instances -
it's now significantly faster in some cases, which may mean you don't
need to resort to the Direct stuff. Of course, if you do, then
generating them with Derive is the way to go.

Thanks, Neil