[Haskell] A collection of related proposals regarding monads

Cale Gibbard cgibbard at gmail.com
Sun Jan 8 08:23:50 EST 2006

On 05/01/06, John Meacham <john at repetae.net> wrote:
> independent of anything else, giving up error messages on pattern match
> failures in do notation is not acceptable. so, if the split were to
> happen, having two methods in MonadZero, one which takes a string
> argument, would be needed.
>         John

Why does that have to be built into the class specification? Already,
GHC can give line/column numbers for failed pattern matches in
lambdas, it should be able to do the same for failed pattern matches
in do-syntax in a similar way.

I've never run into a case where I wanted the pattern match failure
error message in the form of a String, wrapped in my monad datatype
directly. If you were going to go that route, wouldn't a proper data
type be preferred anyway, rather than a String? I can't actually do
anything with that string other than to display it, since the report
doesn't standardise its structure.

Further, these cases seem sufficiently rare that if you're interested
in catching information about where the pattern match failed, and
using it in your program, you'd probably be better off actually
handling failure directly, rather than relying on some system built
into do-notation. Otherwise, what's wrong with just letting the thing
throw an exception with a meaningful error message?

The whole reason things switched to this from the way that they were
in Haskell 98 is that apparently people found it confusing that
refutable pattern matches in their do-blocks were causing these extra
MonadZero typeclass constraints. That may be true, though I'm not sure
it's really a language problem so much as a teaching problem.

Further, pattern matches can switch from being irrefutable to
refutable simply by modifing/extending a datatype, and some found it
confusing that they now had a bunch of MonadZero errors cropping up
after extending their type. Now, I think that this is a bit of a poor
example. In reality, you probably want those error messages -- they
serve as a major warning that your code is now probably incorrect, as
it fails to deal with a potential case in your data type. Improve the
error messages in the compiler if it's confusing.

(People should be more aware that algebraic data types are not meant
to be easily extensible. This is another good reason to want proper
records, as they should take care of situations in which one expects
data to be extended after the fact.)

Does anyone have a real example of a nontrivial use of fail where the
string argument was really important and which wouldn't be better
served by MonadError, or by just throwing an exception? Usually when I
define my monads, I try to ignore 'fail' as much as possible. In most
cases, I just leave it completely undefined, as there's no sensible
way to embed strings into my type, or even to fail properly at all.

Personally, I'd be most happy with just going back to the Haskell 1.4
way of handling do-notation, and I see the reasons for adopting 'fail'
in the first place as a bit specious.

 - Cale

More information about the Haskell mailing list