2010/12/14 Tillmann Rendel
Hi,
John Smith wrote:
I would like to formally propose that Monad become a subclass of Applicative
A lot of code would break because of this change, but all problems should be reported at compile time, and are easy to fix. In most of the cases, either adding obvious Functor and Applicative instances to a library; or deleting such instances from a client, I would expect. This kind of clean-up would actually increase the quality of the library, however, and might therefore be acceptable.
The change is described on the wiki at http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal
There you write, among other things:
fail should be removed from Monad; a failed pattern match could error in the same way as is does for pure code.
How is this part of the proposal related to Functor and Applicative?
Since code depending on the current behavior can not be detected at compile time, this is a more serious change in a way: code keeps compiling but changes its meaning. Can you estimate how much code would break because of this change?
Would it be possible to keep user-defined failure handling in do notation without keeping fail in Monad?
When this change was made for the 'Either' monad, I remember that it introduced sneaky runtime bugs into the, I think, HTTP library. So your concerns are founded. I really think that these proposals should be considered separately, even if they would be enacted at the same time if they both passed. Antoine