On Mon, 3 Nov 2008, Svein Ove Aas wrote:
On Mon, Nov 3, 2008 at 4:55 PM, Henning Thielemann
I think it is a good idea to switch this feature on and off by a compiler switch. It does not alter the correctness of a program. If the program is incorrect, the switch does only affect the way how the program goes wrong.
I disagree. In a normal program, you may want to mix the two - use the safe functions for untrusted input, the unsafe ones once you have already validated the input.
Such a switch, if it existed, should only affect the *unsafe* version of the call - this way, it would be possible to remove all chance of corruption from a program at need.
Also, of course, the exceptions should be catchable based on the new ghc 6.10 exception library (on ghc 6.10, anyhow)
I think you mix up errors and exceptions: http://www.haskell.org/haskellwiki/Exception http://www.haskell.org/haskellwiki/Error If you read untrusted data and encounter an index out of range, then you must throw an exception (or return an "exception code"). The internal array bound checking must be active though, since your code that checks the untrusted data may be buggy. The internal array bound checking is entirely intended for revealing buggy code, not for validating untrusted data. That is, for debugging you turn the bound checking on and if you are sure it is exhaustively tested, then you can turn it off for maximum efficiency. You may want to give http://hackage.haskell.org/cgi-bin/hackage-scripts/package/explicit-exceptio... a try.