G'day all. Quoting Jeff Heard <jefferson.r.he...@gmail.com>:
I don't think that making Show a type class was a mistake.
I don't either. Two main reasons: 1. [Char] should not be shown ['l','i','k','e',' ','t','h','i','s']. 2. Default implementations of Show can break abstractions by leaking implementation details.
I think that we have long since overloaded the meaning of Show and made it ambiguous. There are multiple distinct reasons people use Show, and this gets confusing. It would be good if we as a community tried to nail down these different meanings that people tend to attach to Show and fork out new type classes that each encompass those meanings. Text is useful and often ignored as a means of debugging, inspecting, logging, and serializing.
I tend to agree. Some thoughts: - Show is what print outputs and what GHCi reports. Therefore, to most programmers, it's primarily for human-readability regardless of what the standard says. - Read is barely useful as-is. Don't get me wrong; the "read" function has a very handy interface, especially if all you need is to convert a String into an Integer. But I'd wager that the majority of the most expert of expert Haskellers couldn't write a custom Read instance without constantly referring to the documentation and/or example code. In addition, very few people are aware of the performance characteristics of "reads". - If you want serialisation and deserialisation, Show and Read are poorly-suited for it. A real solution requires handling tricky cases like versioning, redundancy (e.g. computed fields), smart constructors etc. - If what you actually want is parsing and/or pretty-printing, we have some great solutions for that. Cheers, Andrew Bromage _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
