Unboxed arrays of Char are broken

[Marcin 'Qrczak' Kowalczyk]

Sat, 30 Dec 2000 10:40:30 +1100, Manuel M. T. Chakravarty <chak@cse.unsw.edu.au> 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)) '.'
instead.

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 * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK