
2009/9/29 Paulo Tanimoto
Hi Bryan and others,
On Mon, Sep 28, 2009 at 5:29 PM, Bryan O'Sullivan
wrote: bytestring predates the other two libraries by several years. The underlying stream type for uvector and text are almost the same, so they could in principle be merged. There's a fair amount of duplication there, but uvector is in some ways more complicated and in others much less thorough than text. Merging them would be a lot of work!
If I may free-ride on this thread: how should one go about deriving a Data.Binary instance for text? It looks like doing it efficiently would require using some parts of the internal module that are not exposed, am I correct? I've been using "encodeUtf8", but that doesn't feel right. I don't know what to do, hopefully I'm missing something simple.
This is a good point, I also need to make Data.Text an instance of a few basic classes and I am not sure that I did it correctly. So far I have: import Data.Text instance Binary Text where put = put . encodeUtf8 get = liftM decodeUtf8 get -- DOUBT: Is this correct also for Data.Text.Lazy ? instance NFData Text instance Serial Text where -- DOUBT: is this efficient? series d = [T.pack (series d :: String)] -- DOUBT: how to define this coseries rs = error "coseries" More in general: what is the right policy for instances definition? Should the library author provide them, at least for the most common and appropriate classes (at the cost of adding some additional dependencies) ? Should they go in a separate package? Should the Haskell Platform team provide some guidance on this point to library authors? titto

Hi Titto,
On Tue, Sep 29, 2009 at 3:15 AM, Pasqualino "Titto" Assini
More in general: what is the right policy for instances definition?
Should the library author provide them, at least for the most common and appropriate classes (at the cost of adding some additional dependencies) ?
Should they go in a separate package?
Should the Haskell Platform team provide some guidance on this point to library authors?
titto
Thanks for changing the subject, I forgot to do that. I have a similar derivation for a Data.Binary instance, but after looking at Text.Internal, I got the impression that it wasn't as efficient as it could be. But yes, in general this boils down to your questions. I do remember someone asking a similar question perhaps a year or so ago. Now that we have Haskell Platform, does that change anything? In particular, I believe Data.Binary is proposed for inclusion in the platform. Regards, Paulo

On Tue, Sep 29, 2009 at 1:15 AM, Pasqualino "Titto" Assini < tittoassini@gmail.com> wrote:
This is a good point, I also need to make Data.Text an instance of a few basic classes and I am not sure that I did it correctly.
So far I have:
import Data.Text
instance Binary Text where put = put . encodeUtf8 get = liftM decodeUtf8 get
Well, independent of the implementation (yours seems fine, by the way), we can't have Platform packages depend on non-Platform packages. The text library isn't in a position to make it ready for inclusion there yet, but it's getting close, and it might even get there before binary. So it's no problem to write an NFData instance, but a Binary instance would be an issue. -- DOUBT: Is this correct also for Data.Text.Lazy ?
instance NFData Text
instance Serial Text where -- DOUBT: is this efficient? series d = [T.pack (series d :: String)] -- DOUBT: how to define this coseries rs = error "coseries"
What's Serial?
participants (4)
-
Bryan O'Sullivan
-
Malcolm Wallace
-
Pasqualino "Titto" Assini
-
Paulo Tanimoto