News for hackers. Stuff that matters.
Re:State Monad for the Rest of Us by Izkata on Friday August 09, 2024 @10:50AM (#41202417)
They are an abstraction of a sequence of operations, not the state used in those operations.
Re:State Monad for the Rest of Us by darby_nine on Friday August 09, 2024 @10:56AM (#41202471)
They're both, right? It's not like it specifically ignores the inputs and outputs of those operations. These are specifically entailed in the definition of the monad.

I strongly, strongly suspect there's something about how F# processes monads in the context of a do expression that explains what is the focus here.

Unfortunately I don't have the time to go through the steps now, hence why I specifically recommended modifying the introduction to give some clue about the terms involved.

Re:State Monad for the Rest of Us by Izkata on Friday August 09, 2024 @11:14AM (#41202657)
An "if" statement or "map" function also has inputs and outputs and probably some internal state due to implementation details, but we don't say they represent state either. They represent operations, or a sequence of operations.
Re:State Monad for the Rest of Us by darby_nine on Friday August 09, 2024 @12:26PM (#41203292)
> An "if" statement or "map" function also has inputs and outputs and probably some internal state due to implementation details, but we don't say they represent state either.

They absolutely are in the context of a program and not just abstract expression, which never matters. The distinction strikes me as meaningless. At the very least it's worth qualifying with "mutable state" if that's the attribute of state you care about. There's still "constant expressions" as other forms of values and "statically initialized values" as other forms of state.