Henning Thielemann wrote:
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).
I would prefer all exceptions - whether or not they are errors - to be handled using the same mechanism. The distinction between what you call "exceptions" and "errors" can be reflected in the hierarchy of Exception objects. For technical reasons, it may still be necessary to have separate mechanisms for pure exceptions and IO exceptions, but we should try to make these compatible as much as possible.
Exception handling should be done with an ErrorT monad transformer... This should be implemented on top of existing IO...
Unfortunately, that is not possible currently. There are primitives, such as "bracket", that do not support this. The IO system itself would need some modification. But it doesn't seem like that would be too hard, as discussed on this list previously. I wrote:
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.
Yes, I was describing the minimal two-step deprecation process. That makes sense only if we are already certain that the new version is production quality. If not, then we need at least a three-step cycle. But don't forget that although Haskell is now also used for production software, it's also still a research language. So there is a need for steady progress at a brisk pace. Since we do have confidence that this proposal is worthwhile, I suggested the two-step cycle as a compromise.
I would not remove the current modules for a long time.
Also a good idea. But given the current assumption that the module names will remain the same, there will still be a need to make small changes to old code to get it to work. Which means bitrot will begin setting in quickly.
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.
Indeed. But I don't think a naming scheme will be enough, and it won't be easy. This is really the same versioning issue that people have been working so hard on for Cabal, except more granular, at the module level.