> Personally I think fail is a terrible wart, and should be shunned. So do I. I can't understand its purpose since monads which can fail can be implemented through MonadPlus.
2010/5/8 Ross Paterson <r...@soi.city.ac.uk> > On Sat, May 08, 2010 at 07:49:57AM +1000, Ivan Lazar Miljenovic wrote: > > Limestraėl <limestr...@gmail.com> writes: > > > 2010/5/1 John Millikin <jmilli...@gmail.com> > > > > > >> You might want to make a local version of ErrorT in your library, to > > >> avoid the silly 'Error' class restriction. This is pretty easy; just > > >> copy it from the 'transformers' or 'mtl' package. > > >> > > > Yes, I wonder why mtl is not updated so as to remove this restriction. > > > > Presumably because its in "maintenance mode" (i.e. it only gets > > changed/updated to reflect changes in GHC that might affect it and the > > API is frozen). > > The API isn't frozen -- it can be changed with a library proposal, > if you can get people to agree to it. > > As Ryan said, the Error constraint is there to support a definition of > the fail method in the Monad instance for ErrorT. (Personally I think > fail is a terrible wart, and should be shunned.) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe