[Haskell-cafe] Data.IArray rant
Andrew Coppin
andrewcoppin at btinternet.com
Tue Sep 6 19:40:34 CEST 2011
>> It's rather that some considered the IArray API to be
>> inadequate most of the time. Really, H98 arrays aren't very
>> good at anything they do. For collective operations, you are
>> supposed to convert the array to a list, work on the list and
>> then convert it back to an array which just seems wrong.
>
> I am unconvinded that this is any more wrong than using a for
> loop in an imperative language. Remember that the lists are
> lazy, so it’s misleading to say “convert the array to a list”
> since what happens most of the time is that elements are taken
> out of the array and passed to the processing function and then
> thrown away before the next element is processed.
You're still needlessly allocating and then garbage collecting memory
though.
My personal feeling is that Haskell programmers use lists a lot when
what they really want are "streams" (in the sense of the stream-fusion
library). I don't want you to actually *make* a physical list, I just
want to abstract over something that sequentially generates data.
But then, lists are in the standard Prelude, and hard-wired into the
language syntax. Streams aren't exposed by any moderately standard
library. Even the stream-fusion library treats streams as a sort of
"under the covers" thing to deforest lists. My humble opinion is that
half the time when people create physical lists, what they really mean
is a data pipeline that doesn't need to physically materialise at all.
But anyway... Haskell '98 arrays may have fancy indexing, but I've
always wished that there had been a plain ordinary integer-indexed array
construct, with the fancy indexing implemented on top of that, so your
use of fancy indexing is /optional/. I get the distinct impression that
the default array libraries are so barren just because nobody really
used them much, and that was then and this is now, and it's a major pain
to break something that so much code is written against...
I just hope we don't end up with a bazillion different array
implementations popping up. But we'll see.
More information about the Haskell-Cafe
mailing list