BAL paper available

[Simon Marlow]

>=20
> I don't like the idea of a program working which compiles only under
> compilers which have certain language extensions built in.=20
>=20
> If I understand things correctly, there is a list of language=20
> extensions
> (FFI for example), which has been accepted by all Haskell=20
> compilers developers. If
> multiparameter type classes were in that list, I would agree.
>=20
> Besides, MArray.lhs uses ST and ST requires not only=20
> multiparameter type
> classes, but also explicit universal quantification.

ST doesn't require multiparameter type classes (although MArray does).
It also doesn't require full support for explicit universal
quantification, if runST is known to the 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.

> 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.=20

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?).

> By the way, I'm really surprised by the lack of time=20
> complexity information
> in MArray. I mean, that's the most important thing in arrays=20
> - that one can
> update/read a data in O(1).=20

Point taken, I'll update the documentation to include more of this info.

Cheers,
	Simon