On Thu, 2005-08-04 at 10:58 +0200, Wolfgang Jeltsch wrote:
Am Donnerstag, 4. August 2005 10:21 schrieb Axel Simon:
[...]
Nowadays, you can use one of the MonadState monad
State transformer monads like State and StateT can be implemented without using special language features. So there was always the opportunity to implement something like State or StateT. So, in a way, we always could use the MonadState monads. If ST could be replaced by MonadState monads, ST had never been included in the libraries, I suppose.
Well, MonadState needs multi-parameter type classes, and hence, require much more than ST.
if you want lazy computation (on top of which you can implement state read and write accesses similar to IORefs) or IO-enabled computation (if you use MonadState.StateT and embed an IO monad at the core).
The point is that the MonadState monads don't give you update-in-place. Update-in-place is exactly the reason why ST is there.
Ok, granted. In particular I take your point about array accesses. However, I am not quite convinced that using ST has any advantages over using IO directly. Of course, one could claim that programmers wants to protect themselves from themselves by disallowing arbitrary IO. But if that is the only "advantage" then I'd rather go for the flexibility to use arbitrary IO later on without having to rewrite my whole program. Thanks for you comment, Axel.