very emphatic +1 for me. +1 for nubis bruno who works with me and I know supports this. max On Dec 12, 2011, at 5:52 PM, Simon Marlow wrote:

On 08/12/2011 22:39, Iavor Diatchki wrote:

...

Hello,

when writing simple String parsers, I find implementing this function over and over:

readEither :: Read a => String -> Either String a

I just found out that it is already defined in the module "Text.Read" in the "base" package but, sadly, it is not exported. Would there be any objections if: 1. I was to export it 2. I was to add another convenience function "readMaybe :: Read a => String -> Myabe a" defined in terms of "readEither".

I can't think of any problems that this might cause and it would be very helpful to me and my colleagues.

Discussion period: 2 weeks, so until 22 December 2011.

+1

Simon

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Just parse the human-readable string with another parser, to get the machine-readable error description ;) and don't forget to parse the error your error string parser produces too. +0.7 for proposal, but +1 if we have a nice error ADT :) On Mon, Dec 12, 2011 at 10:24 AM, Ben Millwood wrote:

On Thu, Dec 8, 2011 at 10:39 PM, Iavor Diatchki wrote:

...

Hello,

when writing simple String parsers, I find implementing this function over and over:

readEither :: Read a => String -> Either String a

The only thing that bothers me about this is the fact that the error is a String; I don't think that's a very good type for errors, because only humans can really effectively interpret it. I don't know whether it's worth introducing a new sum type just for the different kinds of read error.

Regardless, readMaybe is definitely a good idea, so +1 for that.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries