On Wed, Jul 22, 2009 at 8:31 AM, Adam Wick
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.