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

[José Pedro Magalhães]

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


Cheers,
Pedro

[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 <jeremy at n-heptane.com> wrote:

> On Sun, Jan 24, 2010 at 5:49 AM, Neil Mitchell <ndmitchell at gmail.com>wrote:
>
>> 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.
>>
>
> 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/<http://community.haskell.org/%7Endm/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
> 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/20100126/32ac7e13/attachment.html