I read some time ago about the Haskell State monad. I thought, Cool! A fully general way to manage states! Lots of things have states, and they need a lot of managing! But then when I actually found the specification, I couldn't make head or tails of it. I kept scratching my head and squinting at it, and I still couldn't see where in the State monad is the state kept? All I could see was some mechanism for deriving a new state from an old one.
Now, as part of the Scala Study Group meetup in San Francisco, I'm working my way through the early access edition of Paul Chiusano and Rúnar Bjarnason's Functional Programming in Scala. Chapter 6 introduces the State monad (without ever using the word “monad”), and now that I'm working in a more familiar programming language I can finally see that, like so many other things in this confusing world, the State monad is misnamed. An instance of it is not a state; it is a transition rule between states.
Why can't people just say what they mean in the first place? If I ever write my own State monad, it's going to be called Transition.
It's called State because it allows you to *model* a stateful, destructively-updating computation, where you can read the state and write to it. The way that one can model a stateful computation in a mathematically pure way is via functions, where each successive "mutation" is really just a function of its old state.
ReplyDeleteYeah, thanks, I get the reasoning behind the name. I'm just saying that naming an operation for the thing it operates on is not the best choice of name, at least if you're trying to make something comprehensible to the uninitiated. Now, if you'll excuse me, I have to car over to the shopping center and grocery.
DeleteSure you don't want to bike over?
DeleteAs they say, in English, any word can be verbed.
Delete