I use a custom Pretty class along with HughesPJ, ala ghc's Outputable. It means I can omit data or print it out in a more readable form (even just rounding floats to %.03f can help a lot), and also get nice layout and wrapping. The downside is a certain amount of boilerplate to write output routines for records. Actually, types with multiple constructors are the most annoying. At some point I should investigate the new generic deriving feature to see if some of that can be automated.
As a user of libraries, I get annoyed when they implement Show to something nonstandard. It makes it harder to figure out how the library works. On Sun, Apr 22, 2012 at 4:20 AM, Ivan Lazar Miljenovic <ivan.miljeno...@gmail.com> wrote: > On 22 April 2012 19:55, TP <paratribulati...@free.fr> wrote: >> On Sunday 22 April 2012 19:37:19 Ivan Lazar Miljenovic wrote: >> >>> Is there any particular reason you're *not* using the defaults? >> >> This is a good question which I have asked myself. I have searched about the >> topic, and found that: >> >> http://blog.romanandreg.com/post/13545420287/haskells-show-and-pretty- >> printing-bad-practice >> >> So, according to this address, Show implementation should be used with Read >> so >> as to have show.read equal to identity: this is the only "good practice >> requirement". >> >> In my case, I use Show to print mathematical expressions, but it is not >> strictly pretty printing (not over several lines as in classical Computer >> Algebra Sytems). Why not using my own Show implementation to do that? > > For exactly the same reason you're discovering: Show/Read exist for debugging. > > Show and Read are meant to produce/read valid Haskell code (modulo > [qualified] imports) so that you can work out what code is going wrong > (and coincidentally used as a quick`n`dirty serialisation method). > > The term "pretty-printing" is meant in regards to producing > _human-readable_ versions of your data (though the pretty-printing > libraries can also be used to produce code formatted for some other > tool to parse, etc.). Show/Read happen to be auto-derivable classes > that implement one such form of pretty-printing (i.e. "printing" > values that look like the actual source code that represents them). > > Let me provide you with a personal anecdote: when I took over > maintaining the graphviz library, it was still using the Show class > for printing (but a proper parser library for parsing), and it was > working with the limited functionality it had. However, whenever I > tried to do something new, I found problems: > > * Existing Show instances meant that it was very difficult to extend > what the library could represent and then print properly. > > * As you've found, it can then be a PITA to debug because you have no > idea what the internal values actually are. > > In the end, I eventually wrote a custom pretty-printing class (the > existing pretty-printing classes had instances that didn't suit, just > like Show) and it's worked a lot better since. > > The only time it's valid to override the default Show/Read instances > is when the constructors aren't exported (e.g. Data.Map), but even > then it should be valid Haskell (if you ignore imports, etc.). > > So leave Show/Read as they are, and write a custom function[s] that > does the actual pretty-printing you want. > > -- > Ivan Lazar Miljenovic > ivan.miljeno...@gmail.com > http://IvanMiljenovic.wordpress.com > > _______________________________________________ > 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
