Maybe-summary was: Re: [Haskell-cafe] Re: [Haskell] ANN: random-access-list-0.1

[Isaac Dupree]

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 libraries at haskell.org 
>> , 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