GHC and the Lazy Functional State Threads Paper

[Thomas Pasch]

> So you can fix it for example by using a specialized version of
> freezeArr inside accumArray, of type
>             (Ix i, IArray a e) => STArray s i e -> ST s (a i e)
> This will give quite general type of accumArray: arbitrary immutable
> array from the IArray class.

freezeArr2:: (Ix i, IArray.IArray a e) => STArray s i e -> ST s (a i e)
freezeArr2 = MArray.freeze

> If the immutable array type used was particularly UArray, it would
> be more efficient to use the corresponding STUArray instead of
> STArray, so freezing could just copy a memory block (there are magic
> specializations in ghc's libraries for such case). But if the element
> type was to remain generic, the type would have to be constrained
> over STUArray

freezeArr3:: 
  (Ix i, MArray.MArray (MArray.STUArray s) e (ST s), IArray.IArray a e) 
  => (MArray.STUArray s i e) -> ST s (a i e)
freezeArr3 = MArray.freeze

Is this the way to do it? I wonder a bit if this triggers the 
optimization if 'a' is of type STUArray. (By the way I still have 
problems to see where unboxed values are a good thing and were 
you should better avoid them.)

In addition I wonder why there are so many array types. Are both
STArray and IOArray really necessary and what's the difference 
between them? What about DiffArray? I'm still surprised by operations
like 'unsafeFreezeArray' and 'freezeArray'. Shouldn't the 
garbage collector juge if there are still other references
to a distinct object?

Regards,

Thomas