Claus Reinke wrote:
To summarize: Monad isn't the proper abstraction for failable/Maybe.
Maybe is an algebraic data type that *exactly* represents the spirit
of what you're trying to do: e.g. Conor McBride said: "Maybe is the
most general abstraction. Requiring (>>=), or even (<*>) seems
excessive. What we need is "any f with zero and return", so why not
pick the canonical, initial, inductively defined such thing?" In this
case the typeclass adds no generality to the function's behaviour
(Maybe can be trivially converted to any other type, with a combinator
even). And the confusion that results, when the function is almost
always used at type Maybe anyway. If you want to read the whole
discussion... if you haven't been subscribed to [EMAIL PROTECTED]
, it's archived:
http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9082
Thanks for the summary. I had been wondering about this
change of mood, and I disagree with the suggestion that
Maybe Nothing is the right replacement for Monad fail.
Whether fail should be in Monad, or whether we really want MonadZero,
MonadPlus, MonadError, or something else entirely has been open for
discussion, but it is easily shown
that Maybe is not the most general abstraction - it loses information
wrt to (Either String), for instance:
Prelude> let {f [] = fail "empty"; f [_] = fail "singleton"; f l =
return l }
okay, I see, it's just that most partial functions in Data.* / container
libraries don't really have multiple failure modes that need
distinguishing. You could say, in a type/information-theoretic mindset,
that even your "f [_]" above loses information because it doesn't vary
based on the _ (and so it isn't reversible) (and this is very common and
normal especially for error messages, but there's a large design space
for places where they're needed, depending on whether a machine needs to
understand the message, etc.) I think we didn't conclude much about
e.g. parser-library return types, because we (thankfully) weren't trying to.
-Isaac
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
