Re: 6.10.4 plans

2009-05-21 Thread Simon Marlow
On 21/05/2009 00:38, Ian Lynagh wrote: Hi all, Unfortunately, since the release of 6.10.3, still more problems have come to light in the 6.10 branch. We are therefore planning to do a 6.10.4 release. For 6.10.4, we will only consider fixes for serious bugs that cannot be easily worked around.

Re: Should exhaustiveness testing be on by default?

2009-05-21 Thread Peter Hercek
Ok, I went with the preprocessor solution only. It is simple, stupid and works well enough ... and template haskell alternative needs it anyway not to be too unportable. Both template haskell alternatives reported Pattern match(es) are non-exhaustive of their own. The second alternative

Re: Should exhaustiveness testing be on by default?

2009-05-21 Thread Neil Mitchell
  Do you really want exhaustiveness, or is what you actually want safety? I want both.  Exhaustiveness checking now and forever, because it's a modular property.  Safety when somebody gets around to implementing whole-program analysis in the compiler I use, when I feel like waiting around

Re: Should exhaustiveness testing be on by default?

2009-05-21 Thread Don Stewart
Catch already does assertion checking (1). Its runtime on moderate to small programs (HsColour in particular) is far less than the time GHC takes to compile them, and I still have no idea what its runtime is on enormous programs (2). An analysis can be whole program and can be slow, one does

Re: Should exhaustiveness testing be on by default?

2009-05-21 Thread Neil Mitchell
Catch already does assertion checking (1). Its runtime on moderate to small programs (HsColour in particular) is far less than the time GHC takes to compile them, and I still have no idea what its runtime is on enormous programs (2). An analysis can be whole program and can be slow, one does

Re: Should exhaustiveness testing be on by default?

2009-05-21 Thread Don Stewart
ndmitchell: Catch already does assertion checking (1). Its runtime on moderate to small programs (HsColour in particular) is far less than the time GHC takes to compile them, and I still have no idea what its runtime is on enormous programs (2). An analysis can be whole program and can be

Re: Should exhaustiveness testing be on by default?

2009-05-21 Thread Neil Mitchell
If Catch says your program will not crash, then it will not crash. I even gave an argument for correctness in the final appendix of my thesis http://community.haskell.org/~ndm/thesis/ (pages 175-207). Of course, there are engineering concerns (perhaps your Haskell compiler will mis-translate

Re: Should exhaustiveness testing be on by default?

2009-05-21 Thread Don Stewart
ndmitchell: If Catch says your program will not crash, then it will not crash. I even gave an argument for correctness in the final appendix of my thesis http://community.haskell.org/~ndm/thesis/ (pages 175-207). Of course, there are engineering concerns (perhaps your Haskell compiler

Re: Should exhaustiveness testing be on by default?

2009-05-21 Thread Neil Mitchell
OK. i'm just trying to get an intuition for the analysis. Catch is defined by a small Haskell program. You can write a small Haskell evaluation for a Core language. The idea is to write the QuickCheck style property, then proceed using Haskell style proof steps. The checker is recursive - it

Re: Should exhaustiveness testing be on by default?

2009-05-21 Thread Don Stewart
ndmitchell: OK. i'm just trying to get an intuition for the analysis. Catch is defined by a small Haskell program. You can write a small Haskell evaluation for a Core language. The idea is to write the QuickCheck style property, then proceed using Haskell style proof steps. The checker is