igloo:

On Sat, Jul 18, 2009 at 09:51:04AM -0700, Donald Bruce Stewart wrote:

...

igloo:

...

Hi all,

Proposal: Remove Control.OldException http://hackage.haskell.org/trac/ghc/ticket/3381

We included Control.OldException in base to help people trying to remain compatible with both GHC 6.8 and GHC 6.10. However, my impression is that most (all?) people who wanted compatibility used the extensible-exceptions package instead.

I'd be very wary of this so early. Try building hackage and tell us what breaks when there is no OldException.

I don't have a reasonable way to do an all-of-hackage build at the moment, but I've unpacked the latest version of each package and grepped for "Control.OldException". Of the 1425 packages, 19 mention it:

Oh, I wonder how many are building with base 3 too. Hmm... we should check that. -- Don

Ian, how about we dreprecate the module instead? -- Don iavor.diatchki:

Hello, Please do not remove OldException. -Iavor

On Sun, Jul 19, 2009 at 9:56 PM, Don Stewart wrote:

...

igloo:

...

On Sat, Jul 18, 2009 at 09:51:04AM -0700, Donald Bruce Stewart wrote:

...

igloo:

...

Hi all,

Proposal:     Remove Control.OldException     http://hackage.haskell.org/trac/ghc/ticket/3381

We included Control.OldException in base to help people trying to remain compatible with both GHC 6.8 and GHC 6.10. However, my impression is that most (all?) people who wanted compatibility used the extensible-exceptions package instead.

I'd be very wary of this so early. Try building hackage and tell us what breaks when there is no OldException.

I don't have a reasonable way to do an all-of-hackage build at the moment, but I've unpacked the latest version of each package and grepped for "Control.OldException". Of the 1425 packages, 19 mention it:

Oh, I wonder how many are building with base 3 too. Hmm... we should check that.

-- Don _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Hello, On Mon, Jul 20, 2009 at 10:11 PM, Duncan Coutts wrote:

On Mon, 2009-07-20 at 09:27 +0300, Iavor Diatchki wrote:

...

Hello, Please do not remove OldException. -Iavor

Can you give any rationale? Are you trying to maintain compatibility with base-3 by using CPP + OldException? Is that significantly easier than using the extensible-exceptions package?

1. I would have to go and change all code that uses exceptions, again. 2. I am not sure how to write backwards compatible code. CPP + OldException is not pretty but it works. 3. The extensible exception package is not Haskell 98 (it uses existentials), so it really would be nice if _it_ was placed in a separate package. On that topic, it would be great if we had a way to see what are all the extensions used by a program (including those used by dependent packages). 4. Ian's proposal did not provide any motivation for this change. Is the benefit the we clean things up a bit? If so, I think that it is a bit soon to do it. -Iavor

Duncan

On 22/07/2009 08:19, Iavor Diatchki wrote:

Hello,

On Mon, Jul 20, 2009 at 10:11 PM, Duncan Coutts wrote:

...

On Mon, 2009-07-20 at 09:27 +0300, Iavor Diatchki wrote:

...

Hello, Please do not remove OldException. -Iavor

Can you give any rationale? Are you trying to maintain compatibility with base-3 by using CPP + OldException? Is that significantly easier than using the extensible-exceptions package?

1. I would have to go and change all code that uses exceptions, again. 2. I am not sure how to write backwards compatible code. CPP + OldException is not pretty but it works. 3. The extensible exception package is not Haskell 98 (it uses existentials), so it really would be nice if _it_ was placed in a separate package.

Not practical, unfortunately. Exceptions are very deeply wired in: they are even dependended on by the Monad IO instance, for example (for "fail", which is well-named), and the Prelude exports catch. Not the extensible version of course, but the Prelude's catch is defined in terms of the extensible catch.

On that topic, it would be great if we had a way to see what are all the extensions used by a program (including those used by dependent packages).

A prerequisite is to make it an error to use any extensions not declared in the .cabal file. We talked about this a long time ago, but never got around to doing anything about it. Having done that, you can easily see what extensions are being used by a package: look in the .cabal file. Cabal-install could figure out the extensions used by dependencies, although it would always include base which uses a raft of extensions, so I'm not sure how useful that would be.

4. Ian's proposal did not provide any motivation for this change. Is the benefit the we clean things up a bit? If so, I think that it is a bit soon to do it.

Ok. We should at least deprecate Control.OldException, so we can remove it in 6.14? Cheers, Simon

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