Re: [core libraries] Future of "Text.Show.Functions" module

What's the benefit of this implementation of Show (a -> b)? Even if it causes the output to be parseable, it's unlikely to typecheck. On 20/10/2014 22:00, Andreas Abel wrote:

Strongly +1 for Show printing valid Haskell.

I'd implement showing for functions as

data Function = Function

instance Show (a -> b) where show f = "Function"

(I would not assume Haskellers expect a Show-ed function to be Read-able.)

For simple user-friendly display we should add a class to Text.PrettyPrint

class Pretty a where pretty :: a -> Doc pretty = text . prettyShow

prettyShow :: a -> String prettyShow = render . pretty

This class should become standard for implementing simple pretty printing (instead of the abuse of Show).

Cheers, Andreas

On 19.10.2014 17:36, Brandon Allbery wrote:

...

On Sun, Oct 19, 2014 at 8:59 AM, Michael Snoyman mailto:michael@snoyman.com> wrote:

I think this really brings up the question of what `Show` should be used for. If the goal is to be simple serialization with `Read` as the inverse[1], then this is clearly a nonsense instance and shouldn't be included.

I think I've said before that it would be nice if we had a specific class for debugging displays, given that Read/Show are generally oriented toward serialization. Sadly, this would end up requiring a lot of repetition, since you couldn't sanely fall back on a default Show instance to get a notional Gist (or whatever) instance.