ok wrote:
On 9 Sep 2007, at 10:05 pm, Axel Gerstenberger wrote:
I am used to work with map, zip and zipWith, when working with lists, however, I could not find such functions for Arrays.
They aren't there for at least two reasons. (1) They are easy to implement on top of the operations that are provided. (EASY is not the same as EFFICIENT, of course.) (2) In some cases it isn't obvious what the operations should be.
I note as a counter-argument that Clean provides, in addition to list comprehension and list generators, array comprehension and array generators, so maps and zips of any arity are directly and transparently available in a very Haskell-like language.
I note as a counter-counter-argument that Clean is free of Haskell's "Ix" baggage, which takes us back to (2).
LOL! Now there's a convuloted argument... Personally, I always use 0-origin arrays. I often forget that it's *possible* to use something else. (The obvious example being tuple indexes...)
zip being a special case of zipWith, let's consider just map and zipWith.
I also find it puzzling that the mutable arrays do not provide an analogue of map with works in-place. (Surely this is the entire *point* of mutable arrays?) I mean, it's not difficult to implement it manually yourself, but we all know that home-grown implementations aren't ideal.
But do you really want aMap's result to have the same bounds as its argument? If not, what bounds do you want it to have? Do you want aZipWith to fail if the arrays haven't exactly the same bounds, or do you want to work with the intersection of their bounds, or what?
How about you specify what bounds you want in the zip call? And it then iterates the two arrays from beginning to end like the normal list-zip does. (Of course, then it has a different arity in addition to a different type signature...)
A worse problem these days is that in the dotted libraries there are so *many* variants of arrays. We need to start writing stuff like
aZipWith :: (Ix i, IArray a1 e1, IArray a2 e2, IArray a3 e3) => (e1 -> e2 -> e3) -> a1 i a1 -> a2 i e2 -> a3 i e3
and this is deeper waters than I am comfortable swimming in.
Yeah, I get the impression that the entire thing wants redesigning. It's too complicated and ad-hoc at the moment. (OTOH, who is going to undertake this?)
(What's the best thing to read to explain functional dependencies for multi-parameter type classes?)
Good question...