Michael, Although I like the idea of improving the way that failures are handled in Haskell, I am having trouble seeing any reason to use your framework. If a function is always assumed to succeed given certain pre-conditions, and somewhere along the lines my code discovers that one of these had been violated, then I throw an exception in order to communicate to myself the manner in which I screwed up. If a function might either succeed or fail for a very specific reason, then I use a Maybe because the caller will know exactly what problem is being signaled by Nothing. If a function might fail for one of many reasons and the caller might care about learning more about the problem, then I use an Either so that I can report the details of the problem. In each of the latter two cases, I can already use monads to handle the errors in a relatively convenient manner. In the first case I usually want the program to die right away and let me know where I screwed up, but if for some reason I wanted to continue even given arbitrary unanticipated problems in a particular computation the I use an exception handler. Given that all of the scenarios that I encounter are already handled by the functionality the standard libraries, it is not clear to me what your framework actually offers. I am not writing this to shoot your framework down, but rather to voice my thoughts aloud in order to hear your response to them, since if there is a use scenario that I am missing in which your framework would be ideal then I would be interested in hearing about it. Cheers, Greg On Dec 6, 2009, at 8:58 PM, Michael Snoyman wrote:
We'd like to announce the next installment of the Failure Framework. Based on feedback, our main goals in this release is to reduce the number of external dependencies and avoid complications with monad transformer libraries at the core of the framework. We have made the following changes:
* Failure is not tied directly to monads anymore. The main typeclass is Failure, which provides the failure function. MonadFailure, ApplicativeFailure and FunctorFailure are provided for convenience. * The Failure typeclass is now located in the failure package, which has no dependencies. All code dealing with transformers and mtl has been factored into control-monad-failure and control-monad-failure-mtl, respectively.
In addition, we are simultaneously releasing the following packages: * safe-failure provides safe versions of dangerous, non total functions, such as head, by returning failures. It depends exclusively on failure. * attempt provides a concrete data type for handling extensible exceptions as failures. It depends exclusively on failure. * control-monad-attempt provides a monad transformer for attempt using the transformers library. We do not provide currently an mtl version of this package, but can provide one if there is demand. * control-monad-exception, explicitly typed, checked exceptions with monadic stack traces.
Below are the links to the packages just released. Enjoy!
http://hackage.haskell.org/package/failure-0.0.0 http://hackage.haskell.org/package/control-monad-failure-0.6.0 http://hackage.haskell.org/package/control-monad-failure-mtl-0.6.0 http://hackage.haskell.org/package/safe-failure-0.4.0 http://hackage.haskell.org/package/attempt-0.2.0 http://hackage.haskell.org/package/control-monad-attempt-0.0.0 http://hackage.haskell.org/package/control-monad-exception-0.8.0 http://hackage.haskell.org/package/control-monad-exception-mtl-0.8.0 http://hackage.haskell.org/package/control-monad-exception-monadsfd-0.8.0 http://hackage.haskell.org/package/control-monad-exception-monadstf-0.8.0
Michael Snoyman, Pepe Iborra, Nicolas Pouillard _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe