> > 2.Nuke MonadZero altogether.
> > add mfail :: m a to Monad instead
>
> Sorry, I don't understand option 2, can you please explain?
* Eliminate MonadZero
* Add 'mfail :: m a' to Monad, with a suitable default decl
* Every do expression has a type in Monad
> Yes. But these subtle differences exist independent of MonadZero.
>
> f x = [fst x]
> g (a,b) = [a]
> h ~(a,b) = [a]
>
> Here it turns out f and h are equivalent and g differs, just as above.
> All that differs with MonadZero is that the type is affected, as well
> as the semantics. Eric and others point out that this may be a good
> thing: better to find out about the difference at compile-time than
> at run-time.
>
> I want to make a different plea: keep the language design consistent!
> Yes, the difference between f, g, h is a wart, but let's have one wart
> repeated, rather than two different warts.
I want consistency too. The f,g,h you give all have the same *type*.
The f,g,h I gave do not. It's the change in type that I object to.
It might be justifiable if the type gave new information, but it
does not. The 'zero' can never be used; there is no justification for
changing type to MonadZero.
The status quo has two advantages
- it's the status quo
- the types are explicable
Incidentally, if we do stay with the status quo, I propose to change 'zero'
to 'mzero'?
see http://research.microsoft.com/Users/simonpj/Haskell/haskell98.html
under Prelude matters near the bottom.
Simon
