[Haskell-cafe] Pretty-printer for Text
Ivan Lazar Miljenovic
ivan.miljenovic at gmail.com
Wed Oct 27 04:32:23 EDT 2010
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
>> That said, 9 packages  do use prettyclass ... out of the 168
>> packages  that use pretty itself  (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
I had to write my own  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?
> 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
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
More information about the Haskell-Cafe