Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a
jules at jellybean.co.uk
Fri Feb 8 04:51:34 EST 2008
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
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
More information about the Libraries