PROPOSAL: Remove Control.OldException

[Evan Laforge]

On Wed, Jul 22, 2009 at 8:31 AM, Adam Wick<awick at galois.com> wrote:
> On Jul 22, 2009, at 3:43 AM, Simon Marlow wrote:
>>
>> On 18/07/2009 13:51, Ian Lynagh wrote:
>>>
>>> Proposal:
>>>    Remove Control.OldException
>>>    http://hackage.haskell.org/trac/ghc/ticket/3381
>>
>> We're planning to have a base4-compat, right?  So we could put
>> Control.OldException in base-4, and leave it out of base-5.
>
> Why not leave it in base-4, mark it as deprecated (with all the attendant
> warnings) in base-5, and remove it from base-6?
>
> I can't imagine its inclusion is harming anything, and marking it as
> deprecated gives us all some warning before our packages suddenly break
> while updating.

Python has a convention like this:

version n -> new feature must be explicitly turned on, nonfatal
warnings on things which will break
version n+1 -> new feature implicitly on, old feature still available
version n+2 -> old feature removed

I think it's worked pretty well for them.  So if ghc had done that, it
would have looked something like:

6.10 -> extensible exceptions available under new library name,
warnings attached to calls of 'try', 'handle', 'throwDyn', 'catchDyn',
usage of Exception type, etc.
6.12 -> extensible exceptions go in Control.Exception, old ones move
to OldException
6.14 -> OldException removed

I recently went through the 6.8 to 6.10 upgrade, and while I did read
about the changes on the list of course when I finally was forced to
upgrade I'd forgotten about them.  A whole stable version where the
compiler emitted warnings would have given me plenty of time to fix at
leisure, rather than suddenly becoming top priority because I'm
blocking on upgrading some other package that needs 6.10.