[Haskell-cafe] Pretty-printer for Text

[Ivan Lazar Miljenovic]

On 27 October 2010 19:19, Stephen Tetley <stephen.tetley at gmail.com> wrote:
> On 27 October 2010 08:57, Ivan Lazar Miljenovic
> <ivan.miljenovic at gmail.com> 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/Data-GraphViz-Printing.html#t:PrintDot

> 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 at gmail.com
IvanMiljenovic.wordpress.com