Proposal: Show and Read for Data.Ord.Down
ekmett at gmail.com
Fri Sep 27 15:47:29 CEST 2013
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
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.
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
> > > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries