Andrew Coppin wrote:

Bertram Felgenhauer wrote:

...

Yes, it's a known bug - a conscious choice really. See

http://hackage.haskell.org/trac/ghc/ticket/2120

It's somewhat ironic that this behaviour was introduced by a patch that made arrays safer to use in other respects.

...so it's *not* going to be fixed then?

It's not going to be fixed by itself - the first comment for the bug report basically asks interested parties to submit a proposal for changing this. Bertram

On Sun, Nov 2, 2008 at 7:53 PM, Andrew Coppin wrote:

Bertram Felgenhauer wrote:

...

It's not going to be fixed by itself - the first comment for the bug report basically asks interested parties to submit a proposal for changing this.

Well I certainly don't have the skill to fix it. (Presumably all that array stuff is hard-wired into the compiler.)

Actually, it isn't. The code - the bounds-checking code, at least - is fairly plain haskell in the Array package. You could take a look and, quite possibly, fix it.

In my opinion, what we should have is

1. An interface that is guaranteed-safe, no matter how inefficient that is.

2. An interface that is guaranteed-efficient, no matter how unsafe that is.

3. It should be extremely easy to switch from one to the other.

You write your code against the safe interface, test it until you're happy with it, and then switch to the fast interface.

Sounds good to me.

Currently, the "safe" interface actually allows out-of-bounds indicies (in a way which reveals the underlying implementation), and the "fast" interface isn't publicly supported. Both of these things should be changed.

Go ahead. :)

Henning Thielemann writes:

I think it is a good idea to switch this feature on and off by a compiler switch.

I agree. Same with Int overflow checking, if it can be done at all. The interesting question is how to name it, the obvious -funsafe-optimization might imply that these optimizations are fun and safe, which is probably misleading :-) -k -- If I haven't seen further, it is by standing in the footprints of giants

Ketil Malde wrote:

Henning Thielemann writes:

...

I think it is a good idea to switch this feature on and off by a compiler switch.

I agree. Same with Int overflow checking, if it can be done at all.

The interesting question is how to name it, the obvious

-funsafe-optimization

might imply that these optimizations are fun and safe, which is probably misleading :-)

-fno-paranoia -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

On Mon, 2008-11-03 at 20:21 +0100, Ketil Malde wrote:

Achim Schneider writes:

...

...

-funsafe-optimization

...

-fno-paranoia

-fno-rd ?

-fpermit-program-to-crash jcc

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.