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 <jer...@n-heptane.com> wrote: > On Sun, Jan 24, 2010 at 5:49 AM, Neil Mitchell <ndmitch...@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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe