[core libraries] Re: Discussion: adding displayException to Exception class

Wed Oct 29 15:09:57 UTC 2014

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 at 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 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
> >
>
> --
> 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 at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141029/8aedf2f6/attachment-0001.html>