On 27 October 2010 09:32, Ivan Lazar Miljenovic
Why not write your own Pretty class for that project then?
Personally I don't like type classes if they're solely for notational convenience. I want them to be a least a convention and its nicer still when they genuinely represent something like Monad, Monoid, Applicative etc. The Pretty class in wl-pprint is a convention. If I'm using HughesPJ for compatibility I'll do without a type class, defining my own is just notational convenience.
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?
If you were specifically working around issues of quoting, maybe there would have been room for an alternative design where an Identifier datatype had two constructors one for simple strings and one for quoted ones. In a nutshell, wl-pprint seems to have got the interface 'right' for my tastes. I like having both named primitive printers and a Pretty class. If I want printers for ShowS types or for Docs that don't need page formatting I always copy Wl-pprint's interface.