On Wednesday 08 January 2003 2:32 pm, Simon Marlow wrote:
Oops, I lied. hPutArray and hGetArray work on arrays of Word8 only, so in order to get non-portable results you need to use castIOUArray, which is already documented as having undefined behaviour.
I guess you must mean it's behaviour has not been defined yet. (Or is it's behaviour undefined by definition? :-)
I tried to use it recently to save an IOUArray of Word32's to a file by castIOUArray'ing it to an IOUArray of Word8's and using hPutArray (AFAICS the only possible way to do this using the current library functions).
It didn't work. For an array of N Word32's using N as the argument to hPutArray only gave me the first N/4 Word32's in the file. Using 4N gave me an error message about buffers. So I ended up not using an IOUArray at all :-(
That's a symptom of the bug that castIOUArray doesn't change the bounds of he array to reflect the new type, so hPutArray thinks you're trying to access the array outside its bounds. The trouble is, to do this properly we'd need to change the type of castIOUArray, so that it can get hold of the information it needs to rescale the bounds. Currently we have castIOUArray :: IOUArray ix a -> IO (IOUArray ix b) perhaps we'd need something like castIOUArray :: (C a, C b) => IOUArray ix a -> IO (IOUArray ix b) where C is some new class that lets you get at the scaling factors for the types a and b. This might be overkill. Alternatively, castIOUArray could take the new bounds as an argument, or we could have a way to replace the bounds of an IOUArray/STUArray (unsafeReplaceBoundsIOUArray?). Comments? Cheers, Simon