On 6 Feb 2008, at 5:17 PM, Jeff φ wrote:
IO(U)Arrays are only one variant of mutable Array, there are also ST
(U)Arrays,
which are often preferred.
I should have worded my question better. The MArray interface is
implemented in both the ST and IO monad. A state monad seems like
a logical place for mutable arrays. However, I don't understand
the motivation for implementing it in IO. Were mutable arrays
added to IO because it would be difficult to write code that does
both IO and manipulates arrays otherwise?
Yes.
As I understand it, the reasons are roughly as follows:
(a) The ST monad is a fairly clever hack, and is some years (4 or 5?)
younger than IO.
(b) You can't have an ST-mutable array as a global variable, but you
can do this with IO. It's ugly, but some libraries are rumored to
require it (see the discussion in http://haskell.org/haskellwiki/
Top_level_mutable_state).
(c) In particular, libraries that need to do I/O and/or FFI are
rumored to be particularly in need of top-level mutable state, so
it's natural to combine the two (or three).
(d) It's very difficult to combine monads. Clean's uniqueness types /
can/ be combined (as could arbitrary state monads). In general, IMHO
what you normally want when combining monads is their coproduct. A
general coproduct is quite ugly, but it simplifies nicely in
particular cases. Clean, by restricting the problem to combining
uniqueness-type-based state monads, can combine monads more easily
than Haskell can in the general case. 15 years ago, when these
decisions were made, it seemed easier to have a single monad.
(e) To a certain extent, IO is the monad in Haskell for `everything
other languages can do that we can't'. That's just the nature of the
beast; the name IO is simply taken from the most prominent example.
So IO's mandate is to do everything C can do better.
(f) Some of use consider the IO monad (and mutable arrays in general)
deprecated for precisely this reason; the rest seem to want C with a
nicer syntax. They use IO, we try to avoid it entirely.
jcc
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
