Re: [Haskell-cafe] Pretty-printer for Text

On 27 October 2010 19:19, Stephen Tetley wrote:

On 27 October 2010 08:57, Ivan Lazar Miljenovic wrote:

...

My main objection to having a Pretty type class is that when having a "reasonably sized syntax tree", aren't you likely to want to have your own custom printing variants rather than the ones in the pre-defined class?  As such, does having a default class make sense if it isn't used?

That said, 9 packages [1] do use prettyclass [2]... out of the 168 packages [3] that use pretty itself [4] (some of which implement their own Pretty class).

For a syntax tree I'd want a class, then I can use pretty at any level. This is helpful in defining the instances as most of the work is delegated to pretty rather than prettyExp, prettyDecl etc. so it keeps the code neat. It is also useful in GHCi where I can just call pretty on something.

Why not write your own Pretty class for that project then? Admittedly, some packages might write their own class because they didn't want to use non-ghc/platform libraries or prettyclass didn't exist then. I had to write my own [1] for two reasons: 1) I needed to be able to differentiate between quoted and un-quoted values, and 2) some of the ways values get pretty-printed are different than just "text . show", which is what all the default instances of the Pretty classes are (with the exception of String). It's this second point that I would wonder how many people would use a default Pretty class: just because I want to print String values one way, does that you mean you should print them that way as well? [1]: http://hackage.haskell.org/packages/archive/graphviz/2999.10.0.1/doc/html/Da...

I can't think that I've ever wanted two different flavours of output for a syntax tree. If I was wanted 'round trip printing' (from parsing to pretty to parsing) I'd have to take a lot of care over white space and layout so I would be needing something more powerful than a pretty printer.

Again, it's not a matter of two different types of output; it's a matter of my way of doing output differs from your way of doing output, even for in-built types. Don't forget, instances are imported and exported implicitly. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com