"Simon Marlow" <[EMAIL PROTECTED]> writes: >> Can we also rely on destructive updates for the monadic arrays?
> In GHC, yes :-) Goodie! One more question: I imagine arrays give an opportunity to optimize by unboxing the contained type -- any chance of that? How much space would an array of Chars consume compared to a list of Chars? Meandering back to the original point of O(1) array access - my feeling is that this should be a specific requirement of the language. I would like to be able to specify the asymptotic time comlexity of my programs, but without knowing how primitives behave, I can't. Usually, I tend to avoid arrays, since I don't know how well they'll behave. Is there a good reason (i.e. not just allowing lazy implementors use lists) for *not* specifying it? > We had a project to run concurrent/parallel Haskell programs on an SMP > machine, but it is currently stalled. There are some significant > problems [...] I see. > The GPH (Glasgow Parallel Haskell) project is the implementation using > PVM, which runs with a distributed rather than shared heap. Yes. So it seems PH is the way to go, then. I'll get around to do some tests, I hope. ATM, it seems I'll use a large globally shared data structure, this sounds a bit unPVM'ish, but I'll look into it. > nevertheless, the GPH folks got some good speedups. (Any GPH folks have any rules of thumb handy?) > Their implementation is lagging a bit behind the current GHC > release, however: I can live with that, I think. Thanks! -kzm -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe