On Wed, 5 Jan 2011, Ian Lynagh wrote:
On Wed, Jan 05, 2011 at 10:22:34PM +0100, Henning Thielemann wrote:
is the best we can have. Why changing the name 'catch' to 'catchIOError' in order to support unqualified import?
http://www.haskell.org/pipermail/libraries/2010-December/015433.html
That doesn't sound like arguments against qualified import. There are two approaches: IOError based exception handling and exception handling based on existential quantification. First one is provided in System.IO.Error (exclusively, after Prelude does no longer export 'catch'), second one is provided in Control.Exception. Both solve the same problem (exception handling) in different ways, thus they use the same names. This sounds like a good idea for me! I can just change the import line and can switch between these approaches easily. That's like having 'take' in Data.List, Data.ByteString, Data.ByteString.Lazy etc. That's the entire purpose of modules and qualified import. Now you may object that these approaches can be easily mixed up, throw something using Control.Exception, and try to catch it with System.IO.Error. The problem from my perspective is, that it was wrong to put another exception handling mechanism with hidden exception information into IO. With a monad that is explicit about exceptions, or at least explicit about the possible existence of exceptions other than IOError, it would not be possible to accidentally mix the two approaches. As I said, I think that the extensible-exception mechanism is an interim solution and I would not like to make the old mechanism look worse (by renaming catch to catchIOError and deprecating Prelude.catch) in order to make extensible-exception look better.