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@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@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries