[email protected]
[Top] [All Lists]

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

Subject: Re: [Haskell-cafe] Re: could we get a Data instance for Data.Text.Text?
From: Neil Mitchell
Date: Wed, 27 Jan 2010 02:21:56 +0000

>> 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.
> Right.. that is the problem with Text. Do you think the correct thing to do 
> for gunfold and toConstr is to convert the Text to a String and then call the 
> gufold and toConstr for String? Or something else?

No idea sadly - the SYB stuff was never designed to work with abstract
structures, or structures containing strict/unboxed components.
Converting the Text to a String should work, so in the absence of any
better suggestions, that seems reasonable.

>> 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.
> We currently use template haskell to generate the Serialize instances in most 
> cases (though some data types have more optimized encodings that were written 
> by hand). However, you must supply the Version and Migration instances by 
> hand (they are super classes of Serialize).
> I am all for splitting the Serialize stuff out of happstack .. it is not 
> really happstack specific. Though I suspect pulling it out is not entirely 
> trivial either. I think the existing code depends on syb-with-class.

If you switch to Derive then you can generate the classes with
Template Haskell, or run the Derive tool as a preprocessor. Derive
abstracts over these details, and also tends to be much easier than
working within Template Haskell (which I always find surprisingly

Thanks, Neil
Haskell-Cafe mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>