On Fri, Oct 9, 2009 at 8:33 AM, Jeremy Shaw wrote:

What are the chances of seeing a, instance Data Text, some day?

I might as well follow up here, since I've sent Jeremy a couple of messages on this subject. I think maybe someone else will have to take a crack at a Data instance for Text, because the documentation for Data.Data is not written in English. In its syntax and structure, it closely hews to what we think of as English, but it is the kind of documentation that can only be understood by someone who already knows what it is going to say. This is an exemplar of my experience with the cottage industry of generic programming in Haskell: I'd really quite like to use the stuff, but for goodness's sake, o beloved researchers, please aim your expository papers at non-specialists once in a while. An endless chain of papers of the form "my technique, which you won't understand, is better than this other technique, which you haven't read about and won't anyway understand, in subtle ways that you won't understand" does not feel to me like progress. Yours in some misery and frustration, Bryan.

On Fri, Oct 9, 2009 at 8:33 AM, Jeremy Shaw mailto:jeremy@n-heptane.com> wrote:

What are the chances of seeing a, instance Data Text, some day?

I might as well follow up here, since I've sent Jeremy a couple of messages on this subject.

I think maybe someone else will have to take a crack at a Data instance for Text, because the documentation for Data.Data is not written in English. In its syntax and structure, it closely hews to what we think of as English, but it is the kind of documentation that can only be understood by someone who already knows what it is going to say.

This is an exemplar of my experience with the cottage industry of generic programming in Haskell: I'd really quite like to use the stuff, but for goodness's sake, o beloved researchers, please aim your expository papers at non-specialists once in a while. An endless chain of papers of the form "my technique, which you won't understand, is better than this other technique, which you haven't read about and won't anyway understand, in subtle ways that you won't understand" does not feel to me like progress. Data is probably the most complex bit of Haskell I've seen, and pretty much needs a full paper to have an idea of what's going on, so I'm not sure it's a typical piece of Haskell (nor even a typical bit of generic

Bryan O'Sullivan wrote: programming) to pick on. I had a crack at a simple proper Data instance, and got as far as needing a Data instance for ByteString#, accompanied by an error I don't fully understand, but I think is telling me that things involving magic hashes are magic: Data/Text/Array.hs:104:35: Couldn't match kind `#' against `*' When matching the kinds of `ByteArray# :: #' and `d :: *' Expected type: d Inferred type: ByteArray# In the first argument of `z', namely `Array' What is the Data instance required for here, exactly? Is it generic transformations, or for generic serialisation (or some other need)? It may be possible to fake the Data instance to cover the needed aspects. I'm not in favour of the boxing/unboxing that Jeremy suggested, because Text doesn't really contain a String, but I'm also not sure that a real Data instance (exposing all the innards) is that great either. By the way: text-0.5 doesn't build for me on my GHC 6.8.2 system with base-3, mainly because you are assuming the class-based exception mechanism from base-4 in the Data.Text.Encoding.Error module, without using the extensible-exceptions package. I'm happy to knock up some patches that fixes it, if you still want to support that configuration? Thanks, Neil.

oops, for the sake of completeness you also need: textType = mkStringType "Data.Text" - jeremy On Oct 9, 2009, at 10:33 AM, Jeremy Shaw wrote:

Sweet!

What are the chances of seeing a, instance Data Text, some day? text would be a great type to use with Happstack, because it is far more memory efficient than String. But it is difficult to do that with out a instance of Data.

For the time being, I have been hacking it with:

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

But, packing and unpacking the Text is obviously not that cool..

For what it's worth, ByteString is normally exported abstract, and just uses, deriving Data. Perhaps we can do the same for text? (I believe there are a number of other examples of types in the 'standard' libraries which are exported abstract, but have Data instances...)

- jeremy _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, Oct 9, 2009 at 1:08 PM, Paulo Tanimoto wrote:

I tried to post a comment to your website, but it may have been lost. It seems that the description for unlines is picking up a comment that was meant for lines':

Thanks, yes, Johan sent a patch in to fix that already. Hooray for open source and distributed revision control systems!