Well, in C/C++, and most any other imperative languages (as you probably
know) is O(1) for both reading and updating arrays. Until Haskell can do
this, I don't think Haskell is a viable option for operating system
design, computer graphics, or embedded applications. Thats a shame
because Haskell can do pretty much anything else, and much better/safer
than imperative languages -- at least until we get CPU's specially
designed to run Haskell code at the machine-level.
I was hoping that Haskell-prime would address this. I could be wrong but
it really comes down to whether or not the Haskell code be optimized to
use arrays in the same way that a C program would. And this optimization
could be explicitly declared by the programmer if the language allowed
for it, right?
Don Stewart wrote:
lennart:
As for array updating, there are many ways to improve the O(n) update.
You can use a tree representation and get O(log n) for all operations.
You can use the array single threaded in the ST monad and get all the
usual array operation complexities.
Or use a history/transaction list to average out the copy cost, or use
fusion to minimise the updates required.
Making pure arrays efficient is a lot of fun, but it's a library issue,
not a language one, necessarily.
-- Don
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
