Proposal: Extensible exceptions
gale at sefer.org
Mon Jul 7 08:34:11 EDT 2008
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
> 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.
>> 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
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.
More information about the Libraries