[email protected]
[Top] [All Lists]

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

Subject: [Haskell-cafe] Re: could we get a Data instance for Data.Text.Text?
From: Jeremy Shaw
Date: Tue, 26 Jan 2010 11:52:34 -0600

Attached is my new and improved patch to add a Data instance to Data.Text. The patch just adds:

+-- This instance preserves data abstraction at the cost of inefficiency.
+-- We omit reflection services for the sake of data abstraction.
+instance Data Text where
+  gfoldl f z txt = z pack `f` (unpack txt)
+  toConstr _     = error "toConstr"
+  gunfold _ _    = error "gunfold"
+  dataTypeOf _   = mkNoRepType "Data.Text.Text"

Which is based on what the Data instances for Set and Map do:

Yay for cargo culting!

It seems like this is better than nothing, possibly the correct answer, and if someone does decide to add better instances for toConstr and gunfold in the future, nothing should break? For happstack-data, I think we only need dataTypeOf. 

The instance I posted before definitely did not have valid toConstr / gunfold instances, so I think we would have noticed if we were actually trying to use them..

- jeremy

On Fri, Jan 22, 2010 at 4:24 PM, Jeremy Shaw <[email protected]> wrote:

Would it be possible to get a Data instance for Data.Text.Text? This would allow us to create a Serialize instance of Text for use with happstack -- which would be extremely useful.

We (at seereason) are currently using this patch:

which basically adds:

+textType = mkStringType "Data.Text"
+instance Data Text where
+   toConstr x = mkStringConstr textType (unpack x)
+   gunfold _k z c = case constrRep c of
+                     (CharConstr x) -> z (pack [x])
+                     _ -> error "gunfold for Data.Text"
+   dataTypeOf _ = textType

This particular implementation avoids exposing the internals of the Data.Text type by casting it to a String in toConstr and gunfold. That is similar to how Data is implemented for some numeric types. However, the space usage of casting in Float to a Double is far less than casting a Text to a String, so maybe that is not a good idea?

Alternatively, Data.ByteString just does 'deriving Data'. However, bytestring also exports Data.ByteString.Internal, wheres Data.Text.Internal is not exported.

Any thoughts? I would like to get this handled upstream so that all happstack users can benefit from it.

- jeremy

Attachment: text-data.patch
Description: Text Data

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