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?
No idea sadly - the SYB stuff was never designed to work with abstract structures, or structures containing strict/unboxed components. Converting the Text to a String should work, so in the absence of any better suggestions, that seems reasonable. >> 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/) 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. If you switch to Derive then you can generate the classes with Template Haskell, or run the Derive tool as a preprocessor. Derive abstracts over these details, and also tends to be much easier than working within Template Haskell (which I always find surprisingly difficult). Thanks, Neil _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
