On Sun, 6 Jul 2008, Yitzchak Gale wrote:
I am now opposed to this proposal as it stands, due to code breakage.
If the proposal breaks code, then it should be implemented in new modules. The opportunity could also be used to correct design flaws, that are in the current IO modules. E.g. there should be strict and lazy readFile: readFileStrict :: ErrorT IO IOError [Word8] readFileLazy :: IO ([Word8], Maybe IOError) Then there should be new modules that strictly separate between error handling (they should be located under Debug) and exception handling (they should be under Control.Monad). Exception handling should be done with an ErrorT monad transformer (only renamed) which uses a type isomorphic to Either but distinct from it. This way exception handling can be used for all monads, not only IO. The great thing is, that this is even everything Haskell 98! This should be implemented on top of existing IO, but the new function should assert not to use the exception facility of IO, but only use ErrorT exceptions. It should be in a separate package which can be installed from Hackage, so people can play with it and improve it.
It might even be possible to get rid of the Error class and use the Exception class instead.
I like that idea. In practice, I always find strMsg and noMsg nothing more than an annoyance. What is really needed is a required Show instance, like the Exception class has.
What is it intended for? Exceptions must be reported to the user in many cases. 'Show' is reserved for emitting Haskell code, but that's not of interest for application users. A widely adopted class for generating user friendly, maybe pretty printed, text, does not exist so far. Application users are even interested in localised messages. So there should be a class which generates localised messages for exceptions.
o For 6.10, make the new Exceptions available so that everyone can start working on switching, but leave old Exceptions as the default so that existing programs still work. Prominently mark old exceptions as deprecated in all documentation.
Please wait a bit even with deprecation. In 6.10 the new exception modules will still be in flow, one should not urge users to skip to this construction site. If the advantages become obvious programmers will skip automatically. I would not remove the current modules for a long time. Module interfaces are never perfect. There will be new type extensions which allow for even nicer function types, and then you want to replace all IO modules, again. It's better to start a naming scheme which is open for future extensions and replacements.