I am now opposed to this proposal as it stands, due to code breakage. However, the proposal is nice, and I think that we could get there via a more friendly path. Discussion and suggestions follow. I wrote:
How does this affect integration between IO exceptions and pure exceptions, in particular Control.Monad.Error from mtl?
Ian Lynagh wrote:
I don't think anything needs to change, but it might be desirable to use a similar sort of extensible-errors.
No, the Error class is already extensible. But Exception members are not suitable, since they do not have strMsg and noMsg methods. With the old Exceptions, that was not too bad - you just need to wrap the single Exception data type. This proposed change makes things much messier, and it will break code.
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. And of course, having all Exception instances available as candidates for pure exceptions is nice. But this would be a traumatic change. There would need to be some migration/deprecation path. As Bulat points out, there will be a lot of pain caused even for Exception itself. The fact that it is easy to figure out how to fix code to make it work again (assuming that is true) will not change the fact that many, many programs will no longer compile. Past experience shows that this causes a lot of damage. To get there with less pain, I think we should: 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. o In the next version, make the new Exceptions the default. Make sure that programs using new Exceptions for 6.10 will still work (e.g., leave NewException as an alias for Exception, or whatever). In parallel, do something similar for deprecating the mtl Error class and using Exception instead. As a general note - it has been suggested several times that we need a facility like Python's "from future import ...". That would be much better than making up names like "OldException" and "NewException" every time. Though in Python itself, that facility only applies to the core language, not to libraries. When an important library is changed in an incompatible way, they tend to use a new name for the new library and leave the deprecated library around with its old name for years and years. We could also do that here. Another approach would be to build this kind of facility into the package system. Thanks, Yitz