Proposal: Show and Read for Data.Ord.Down

[Edward Kmett]

I agree. I really do wish that derived Read/Show for single-parameter
constructors didn't try to show the record syntax.

There is another approach:

I often just wind up writing the 4 lines of Read/Show for simple data types
/ newtypes.

This avoids cluttering my debugging output, while keeping it as a field
accessor so end users can still just

import Foo (Down(..))

and be sure getDown comes along for the ride.

-Edward



On Fri, Sep 27, 2013 at 5:06 AM, Ross Paterson <R.Paterson at city.ac.uk>wrote:

> On Thu, Sep 26, 2013 at 06:16:57PM +1000, Ivan Lazar Miljenovic wrote:
> > On 26 September 2013 18:03, David Luposchainsky
> > <dluposchainsky at googlemail.com> wrote:
> > > On 2013-09-26 06:50, Edward A Kmett wrote:
> > >> I strongly favor creating instances like this.
> > >>
> > >> Not having them just makes the world more painful to debug code to
> > >> make a normative point and leads to greater code fragmentation when
> > >> someone else has another stance.
> > >
> > > I agree. Being able to look at some value "the dirty way" is an
> > > important use case of Show (be it as a return value or via trace), and
> I
> > > see no reason for any datatype to not support Show when it could.
> > >
> > > On Read I don't have an opinion because I usually try to avoid it :-)
> > >
> > > +1
> >
> > +1 from me as well; furthermore, how about an "unDown :: Down a -> a"
> > record function or some such just to avoid the "\(Down x) -> x" usage
> > like how Krzysztof described?
>
> Making it a field will complicate the derived Read and Show instances.
> That can be avoided by adding it as a separate function.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131011/c4016221/attachment.html>