2010/12/14 Tillmann Rendel <ren...@informatik.uni-marburg.de>: > 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe