Array interface refactoring
Donald Bruce Stewart
dons at cse.unsw.edu.au
Wed Feb 22 04:48:08 EST 2006
> On Wed, Feb 22, 2006 at 03:39:48PM +1100, Donald Bruce Stewart wrote:
> > And unsafeRead/unsafeWrite are too verbose. They are usually (almost
> > always?) safe (since the code does its own checks),
> The same can be said about most uses of unsafePerformIO - you wouldn't
> be using it if you weren't certain that your program will behave
> > so perhaps this essential-for-performance interface should have nicer
> > names?
> Any primitive with can destroy the nice properties of Haskell when
> *misused* should be marked as unsafe. The point is that you can do
> anything with other nice, non-unsafe functions and you will still stay
> within the semantics of the language.
> If you don't like those long names, nobody is stopping you from defining
> your own local bindings. Thanks to inlining, it should be as efficient
> as using unsafeWrite/unsafeRead directly.
> > They're not in the same unsafe league that unsafePerformIO is.
> Why not? With unsafeWrite you can write to any address in memory, so you
> can crash the program, change values which should be constant, etc.
> Perhaps unsafeRead is not that dangerous, but you can surely cause SEGV
> with it.
It's not a terribly serious suggestion ;)
I just found that using unsafeRead/Write is very important for shootout
entries (we used it a lot -- it's the only way to beat C), but a lot
uglier on the page than (the equally dangerous) peek/poke, which get
nice short names for some reason.
More information about the Haskell-prime