Array interface refactoring
Alson Kemp
alson at alsonkemp.com
Wed Feb 22 12:59:07 EST 2006
> 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
> properly.
>
> > 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.
Based on a ShootoutEntry discussion that Don and I
had, I was under the mistaken impression that
"unsafeWrite" broke an ST assumption because
"unsafePerformIO" broke an IO assumption.
However, I think that I agree with both of you
because we're using multiple definitions of "unsafe".
I see these as different degrees of "unsafe":
unsafePerformIO - breaks an IO assumption;
unsafeWrite - doesn't do a bounds check...
>With unsafeWrite you can write to any address in
memory, so
>you can crash the program
hmm... If I put an incorrect index into
IArray.write, Ix.index errors and the program
exits/dies/crashes (without SEGV). This doesn't seem
much "safer".
To be "safe":
readArray :: (MArray a e m, Ix i) => a i e -> i -> m e
writeArray :: (MArray a e m, Ix i) => a i e -> i -> e
-> m ()
could be
readArray :: (MArray a e m, Ix i) => a i e -> i -> m
(Maybe e)
writeArray :: (MArray a e m, Ix i) => a i e -> i -> e
-> m (Maybe ())
...but this seems to be carrying it a bit far.
I think that I'd prefer clear markings for different
specializations:
unsafePerformIO - UNSAFE; use with caution;
writeArray - write to an array; returns m (Maybe
()); very safe;
writeArray_q - write _quickly without bounds
check; moderately less safe;
foldl - blah blah;
foldl_s - "foldl" made more _strict.
- Alson
More information about the Haskell-prime
mailing list