Discussion: adding displayException to Exception class

[Michael Sloan]

Agreed!

I think there has been general consensus that when possible, Show
should generate valid Haskell code.  Suppose that you want to
reproduce some bug where a specific set of functions are suspected.
If there arguments are 'Show' instances, then you can output
invocations of these functions to a file.  This file can now be used
as an executable, minimizable reproduction of the bug!

Honestly, I think 'Read' isn't all that important except for things
like parsing numbers, very small applications. and prototypes.  In
practical code, you either end up using a serialization like binary or
aeson, or writing your own pretty printer / parser.  I'd rather have
the property that 'show' results in code than the property that "read
. show === id" (but certainly this is a nice property to have!).

Michael

On Wed, Oct 29, 2014 at 4:25 AM, Michael Snoyman <michael at snoyman.com> wrote:
>
>
> On Wed, Oct 29, 2014 at 1:18 PM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>>
>> If people want Show to generate something that can be copy/pasted into a
>> Haskell source file, that’s a legitimate position.  But please let’s not
>> call it “serialisation”!
>>
>>
>
> To be clear: people in this thread expressed the copy/paste concept. In the
> previous thread, serialization via Show/Read combination was definitely
> advocated. To hopefully flesh out all of the different positions I've seen
> expressed so far:
>
> 1. Express a valid Haskell expression for copy/paste reasons.
> 2. Express a valid Haskell expression to make it easy to determine the type
> of the exception thrown (even though that's not always enough information).
> 3. Express something that can be consumed by Read for easy serialization.
> 4. Print something which is meaningful to a Haskell developer.
> 5. Print something which would be meaningful to an end user.
>
> I agree completely that (3) should be handled by Binary (or equivalent:
> ToJSON/FromJSON, cereal, Storable...). And it seems like (1) and (4) should
> overlap perfectly, with one little exception: there are some things (like a
> Handle, IO action or function) which could be printed but not copy-pasted.
> (2) would likely be handled better via Typeable, possibly with some extra
> plumbing for cases like extensible exceptions.
>
> This is a great time for everyone to jump in with the use cases they care
> about that I've missed...
>
>>
>> So we have:
>>
>> 1.      Serialisation (use Binary)
>>
>> 2.      Copy-pasteable into Haskell source file, but not necessarily
>> human-readable (Show)
>>
>> 3.      Human readable (Display)
>>
>>
>>
>> It’s clearly a library-design issue whether (2) and (3) are worth
>> separating.   More classes, more code, but perhaps more expressiveness.
>> What does the core libraries committee think?  Personally I don’t see (2) as
>> particularly important, but my opinion counts for little since I’m not a
>> library author.
>>
>>
>>
>> Simon
>>
>>
>>
>> From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of
>> Michael Snoyman
>> Sent: 29 October 2014 11:02
>> To: Simon Peyton Jones
>> Cc: libraries
>> Subject: Re: Discussion: adding displayException to Exception class
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Oct 29, 2014 at 10:45 AM, Simon Peyton Jones
>> <simonpj at microsoft.com> wrote:
>>
>> As I recently commented on this list[1], the Show typeclass is overloaded
>> with multiple meanings (serialization, debug info, and user-friendly data
>> display). The general consensus seems to be that the official semantics for
>> Show should be for serialization (as paired up with Read).
>>
>>
>>
>> Really?  My instinct is otherwise: to use Show for human-readable display,
>> and Binary for serialisation.  Show/Read is a terribly inefficient
>> serialisation format; as soon as you want to do it for real you end up with
>> Binary anyway.  And Show is already well established for human-readable
>> purposes – that was one of its primary original purposes.
>>
>>
>>
>> Simon
>>
>>
>>
>> My weak vote in that thread went towards Show for human-readable display,
>> but there was some quite harsh objection to that position. In this thread
>> too you can see people wanting a direct encoding of types which can be
>> copy-pasted into a Haskell source file. Personally, I don't see much need
>> for that, and especially given the new ability to essentially auto-derive
>> Binary instances (via Generic), Show/Read serialization seems fairly
>> pointless.
>>
>> Nonetheless, making a proposal that doesn't enforce a changed semantics on
>> the Show typeclass seems like the path of least resistance. If others want
>> to jump back into the previous topic and try to hammer down the ideal usage
>> of the Show typeclass, I'm happy to participate in that discussion too.
>>
>> Michael
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>