Am Donnerstag, 4. August 2005 11:09 schrieben Sie:
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.
The class MonadState needs multi-parameter type classes but the monads State and StateT don't. If you switch the state and monad argument of StateT, you can also create a class which is a bit less flexible than MonadState but which nevertheless allows State and StateT to be instances of it: class StateMonad sm where put :: s -> sm s () get :: sm s s instance StateMonad State where ... instance Monad m => StateMonad (StateT m) where ... Note that sm in the class declaration has kind * -> *. So, multi-parameter classes have nothing to do with the ability to implement monads like State and StateT. These are just implemented as equivalent to ordinary functions via newtype.
[...]
However, I am not quite convinced that using ST has any advantages over using IO directly.
Of course, it has. As someone already pointed out, you can hide the imperativeness of a ST-implemented algorithm behind a purely functional interface by using runST.
[...]
Thanks for you comment, Axel.
Your welcome. Best regards, Wolfgang