Re^10: Is it worth using Monads in Perl ? and what the Monads are ?by gaal (Parson)
|on Jun 14, 2007 at 20:52 UTC
Basically a variable--the imperative sense of the word--plus some sequence information about who read what value when. Ie. State.
Not quite; or, yes and no. Haskell already had run-of-the-mill mutable vars (called IORef). But STM gains its power from both monads and the fact that there's a typechecker. It's not just some sort of simulated state. You can have ten different functions updating the same TVar, and STM takes care of synchronizing this state across threads. (With no deadlocks and in composable ways; there are slides and a video that explain this very well.) And it's just TVars that you can update this way; your code won't compile if you try to update an IORef that's not part of the concurrency celebration.
Of course it is! But the benefit that's missing is a typechecker, of the kind that doesn't let you compose functions that wouldn't make sense. How do you tell a function is pure in Perl? You read its code. But surely, the compiler could have figured this out at least?
Having good reason to believe a function is pure can be quite convenient. Your runtime could, for example, decide by default to memoize all pure functions automatically. If the compiler could prove a function only accepts one arg and that arg is a single byte in width, this can be a very cheap optimization! (Who knows, the compiler might precaluculate all possible output values if there were very few of them.) With an impure function, you simply have no grounds to do this, since you don't know if the function is looking at some other concealed input (of if indeed the caller wants it to produce some side-effectual output).
Regarding idiots, sorry, I was using the wrong word. I wasn't referring to anybody's intelligence, but rather to how some people deal with newcomers superciliously. I believe a better term is "gratuitously unpleasant person", though others may also be applicable.