Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a

[Jules Bean]

Dan Doel wrote:
>     readEither s =
>       case [ x | (x,"") <- readPrec_to_S read' minPrec s ] of
>         [x] -> Right x
>         []  -> Left "Prelude.read: no parse"
>         _   -> Left "Prelude.read: ambiguous parse"

Because there are multiple error cases, I support the Monad version.

I agree with everyone who has said that fail is a wart, but since we 
don't have a haskell98 'MonadStringError', and 'MonadError' requires 
fundeps and MPTCs, I think fail is the best we have at the moment.

If we were prepared to endorse fundeps and MPTCs then I might support a 
(Error e, MonadError e m,Read a) => String -> m a type.

If there was only one error case, then Maybe would contain enough 
information, and I would support the simpler version. As there are three 
(no parse, ambiguous parse, and incomplete parse), it is losing 
information just to product Nothing.

+1 for Text.Read.readM from me.

Dan points out in conversation that a MonadPlus constraint might be 
considered a 'valid hint' that fail is a sensible operation.

Without wishing to derail the conversation, common combinators to 
promote and demote error types might be good thigns to document and 
possibly even include in the standard lib. One example which springs to 
mind is

maybe (fail "it went wrong") return

which the combinator to "promote" from unlabelled errors (Maybe) to 
labelled errors (presumably in an error monad). Or with a custom error 
type, something like

maybe (throwError ThereWasAProblem) return

which could be set up as an infix like this:

possiblyFailingOperation `withError` ThereWasAProblem

There are a whole bunch of tricks like this for embedding one error 
strategy inside another which are 'obvious' and even 'folklore' but not 
written down.

Jules