Unboxed arrays of Char are broken
Marcin 'Qrczak' Kowalczyk
30 Dec 2000 16:14:24 GMT
Sat, 30 Dec 2000 10:40:30 +1100, Manuel M. T. Chakravarty <email@example.com> pisze:
> I don't understand why having allocation without initialisation
> slows down allocation of initialised, boxed arrays.
Currently I have to write:
graph <- newArray ((0,0),(59,9))
sequence_ [writeArray graph ij '.' | ij <- indices graph]
which allocates an array, fills it with bottoms and fills it again
with dots. (And the second fill does unnecessary bounds checking
unless the compiler is really smart.)
I would like to write
graph <- newArray ((0,0),(59,9)) '.'
Fragment of current MArray.hs:
instance MArray IOArray e IO where
readArray = readIOArray
writeArray = writeIOArray
newArray ixs = newIOArray ixs io_bot
io_bot = error "IOArray: undefined element"
--ToDo: throw (ArrayException UndefinedElement)
I would let newArray take the value to use in place of io_bot.
> Overall, the Haskell array interface isn't really great for
> performance, but it is definitely not the array initilisation loop
> that causes the problems.
I am looking for a reason why arrays are currently born uninitialized.
If the reason is performance in case one does not want to initialize
the array with a single value, I am replying with a similar case when
it causes double initialization, so it must be not that reason.
> I definitely need the non-initialising version
You can always pass bottom (or zeros in case of unboxed arrays)
to the initializing version.
__("< Marcin Kowalczyk * firstname.lastname@example.org http://qrczak.ids.net.pl/
^^ SYGNATURA ZASTĘPCZA