[Haskell-cafe] "desactivate" my Show instance implementations temporarily

[Evan Laforge]

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.miljenovic at gmail.com> wrote:
> On 22 April 2012 19:55, TP <paratribulations at 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.Miljenovic at gmail.com
> http://IvanMiljenovic.wordpress.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe