2009/9/29 Paulo Tanimoto <tanim...@arizona.edu>: > Hi Bryan and others, > > On Mon, Sep 28, 2009 at 5:29 PM, Bryan O'Sullivan <b...@serpentine.com> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe