On Wed, 16 May 2001, Simon Marlow wrote:
Besides, MArray.lhs uses ST and ST requires not only multiparameter type classes, but also explicit universal quantification.
ST doesn't require multiparameter type classes (although MArray does).
You're of course right.
It also doesn't require full support for explicit universal quantification, if runST is known to the compiler.
So it's another thing to put inside a compiler?
Also, the ST array types are really an optional part of the MArray interface - it works perfectly well with just the IO array types.
Perhaps. It just shows that the module was created specifically for ghc.
I don't like ST and the idea that someone who wants to use arrays outside of IO has to use ST gives me creeps.
What would you suggest as an alternative? I suppose you could have a monad which just supported a single array, but special-purpose monads tend to be a pain in practice (eg. what happens when you want two arrays?).
I'd rather have a monad which just supports a single array as a standard and IO/STArray as a language extension, than the other way. You could tell the same about MonadState. And I've never needed to use ST - somehow MonadState was always enough. And I vaguely remember some problems with typing when I tried to use ST once. IOArray is better - though it is unnatural to be forced to use IO whenever one wants to do something on arrays. So, in the end, if I were to choose between STArray, IOArray and a monad with a single array, I'd choose the monad. Though the best solution probably would be to support all of them. I don't know how the TODO list of nhc developers looks like, but if they aren't implementing multiparameter type classes now, it probably (disclaimer: I am not a Haskell compiler developer) would be easier to implement a simple monad, than type classes + ST.
Simon
Wojciech Moczydlowski, Jr