Hi,
>Erik Meijer also spoke up vigorously in defence of MonadZero.
The reason for this is that I want the type-checker to catch as many errors
as possible.
>But the Haskell 1.4 story is unattractive becuase
> a) we have to introduce the (new) concept of unfailable
Compared to many other concepts in the report (layout rule, monomorphism
restriction, defaults, irrefutable patterns, newtype, Numeric types), this
is one of the easiest to understand.
> b) if you add an extra constructor to a single-constructor type
> then pattern matches on the original constructor suddenly become
>failable
That is great. I'd rather have this as a static error that getting an
unexpected pattern match failure in my nuclear reactor device driver:
data Position = Open | Close
controlReactor = do{ .....; Open <- checkValve; ... }
than have this fail silently using the default definition mfail = undefined.
>The only plausible ones seem (2) [nuke MonadZero] and (5)[status quo].
I agree that these are the two plausible ones (Mark proposes (2) while
retaining MonadZero for backwards compatibility, which is better tha (2) but
still reduces static typedness).
My proposal is to stick with the status quo and make IO an instance of
MonadZero (using userError) and MonadPlus (using catch). If users are smart
enough to define their own monads, they should be smart enough to understand
the concepts of MonadZero and failure-free matching.
Erik
