BAL paper available

[Wojciech Moczydlowski, Jr]

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