Re:State Monad for the Rest of Us
by wavemode on Friday August 09, 2024 @11:01AM
(#41202521)
I think "context" is a bit more all-encompassing.
If I have an Int, then I just have an Int.
If I have an Identity Int, then I really still just have an Int.
If I have a [Int] then I have a list of Ints.
If I have a Maybe Int, then I either have an Int or I have Nothing.
If I have a Reader r Int, then I have a computation taking some input of type r and producing an Int. That computation can't modify the value of r.
If I have a State s Int, I have a computation taking some initial state of type s and producing an Int. The value of s may change during the computation.
All of these are monads, but calling all of them "state" is somewhat reductive.
The Haskell wiki tutorial on monads refers to them vaguely as "strategies" - I mostly agree with that description.
If I have an Int, then I just have an Int.
If I have an Identity Int, then I really still just have an Int.
If I have a [Int] then I have a list of Ints.
If I have a Maybe Int, then I either have an Int or I have Nothing.
If I have a Reader r Int, then I have a computation taking some input of type r and producing an Int. That computation can't modify the value of r.
If I have a State s Int, I have a computation taking some initial state of type s and producing an Int. The value of s may change during the computation.
All of these are monads, but calling all of them "state" is somewhat reductive.
The Haskell wiki tutorial on monads refers to them vaguely as "strategies" - I mostly agree with that description.