
In the presence of fusion (as is the case in uvector), it's hard to
give meaningful time complexities for operations as they depend on
what operations they are paired with. We need to think of a better way
to express this behavior in the documentation though.
On Tue, Nov 3, 2009 at 9:12 PM, brian
Really, arrays in Haskell are the most @#!$! confusing thing in the world.
There's a bunch of different array structures.
I can't tell which one works best, and all I want to do is x[i] = value.
I thought uvector was the answer, you know, fast unboxed ARRAYs. Imagine my surprise when I saw this
indexU :: UA e => UArr e -> Int -> e
O(n). indexU extracts an element out of an immutable unboxed array.
An array implementation with an order N lookup. huh ?? That's not an array, that's a list. I was looking for an array.
However, I then found in the same hackage:
readMU :: MUArr e s -> Int -> ST s e
O(1). readMU reads the element at the specified index of a mutable unboxed array.
So O(1) for mutable, but O(n) for immutable ? See, confusing... I'm sure there's a really good, lofty type safety, something or other reason for that, that I'm sure I don't care about ;-)
There's also ST. So why is there a uvector, when there's ST ??
etc, etc, etc...
and then there's monads...
other than that, having fun with haskell :-)
Brian
On Nov 3, 2009, at 3:42 PM, David Leimbach wrote:
On Tue, Nov 3, 2009 at 2:16 PM, Tracy Wadleigh
wrote: I had to implement a ring buffer, and I wanted the code using it to be written in Haskell. I ended up implementing the buffer in C, and wrapping it in FFI from Haskell because implementing a destructive array in Haskell is kind of unwieldy to someone of my experience level. In Clean, it looks like the uniqueness typing allows for destructive updates in a very controlled manner.
The ST monad provides this functionality. The never-instantiated-in-a-visible-way state parameter of the ST monad provides the "uniqueness" required for doing destructive updates in a pure way.
Someone suggested that to me on IRC once I'd already cranked out a C implementation with FFI bindings. It's just too easy to use the FFI in Haskell :-)
If we raise the barrier of FFI, more people will use ST!
Dave
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe