[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: José Pedro Magalhães
Date: Tue, 26 Jan 2010 08:39:20 +0100
Hi Jeremy,

As Neil Mitchell said before, if you really don't want to expose the internals of Text (by just using a derived instance) then you have no other alternative than to use String conversion. If you've been using it already and performance is not a big problem, then I guess it's ok.

Regarding the Serialize issue, maybe I am not understanding the problem correctly: isn't that just another generic function? There are generic implementations of binary get and put for at least two generic programming libraries in Hackage [1, 2], and writing one for SYB shouldn't be hard either, I think. Then you could have a trivial way of generating instances of Serialize, namely something like
instance Serialize MyType where
  getCopy = gget
  putCopy = gput

and you could provide Template Haskell code for generating these. Or even just do
instance (Data a) => Serialize a where ...

if you are willing to use OverlappingInstances and UndecidableInstances...


[1] http://hackage.haskell.org/packages/archive/regular-extras/0.1.2/doc/html/Generics-Regular-Functions-Binary.html
[2] http://hackage.haskell.org/packages/archive/multirec-binary/0.0.1/doc/html/Generics-MultiRec-Binary.html

On Tue, Jan 26, 2010 at 03:16, Jeremy Shaw <[email protected]> wrote:
On Sun, Jan 24, 2010 at 5:49 AM, Neil Mitchell <[email protected]> wrote:

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

- jeremy

Haskell-Cafe mailing list
[email protected]

Haskell-Cafe mailing list
[email protected]
<Prev in Thread] Current Thread [Next in Thread>