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

[Ganesh Sittampalam]

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 <michael at snoyman.com
>> <mailto:michael at 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.
> 
> 
>