I could definitely see adding a separate displayException method to Exception. 

+1 there.

Removing Show as a superclass however is something we'd have to check, its the kind of thing where it'd silently affect some code that was just accepting the exception and printing it in a manner that could be worked around by using a pair of constraints, just like the change breaking up Num that Ian put through a few years back.

If that is something folks really want to do, we could probably get there.

If we did then you'd probably want

class Typeable a => Exception a where
   ...
   displayException :: a -> String  
   default displayException :: Show a => a -> String
   displayException = show
  
which would let most of the existing code around it work, and only break the code that takes an exception blindly and prints it.

Adding displayException strikes me as easy, and zero-pain. 

Removing Show on the other hand is something I'm somewhat less sanguine about, but not either for or against.

-Edward

On Wed, Oct 29, 2014 at 9:56 AM, Michael Sloan <mgsloan@gmail.com> wrote:
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@snoyman.com> wrote:
>
>
> On Wed, Oct 29, 2014 at 1:18 PM, Simon Peyton Jones <simonpj@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@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@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@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

--
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.