Comments on: A monad tutorial for Clojure programmers (part 3)

By: Protecting mutable state in the state monad « On Clojure

Protecting mutable state in the state monad « On Clojure — Wed, 24 Jun 2009 16:21:46 +0000

[...] mutable state in the state monad Filed under: Uncategorized — khinsen @ 4:19 pm In part 3 of my monad tutorial for Clojure programmers, I explained that the main purpose of the state monad [...]

By: Tim Levin

Tim Levin — Wed, 17 Jun 2009 19:39:13 +0000

I think that ease of understanding monadic code is a key issue, which is distinct from “ease of use” (for the programmer). For code that MUST be understood in detail by others (e.g., in situations requiring high assurance of security policy enforcement), macros and new language features that make the semantics of monads more explicit, and thus clearer, can be very helpful. One man’s clutter is another man’s key, I suppose, but in my view, the use of raw monads and related transformers is problematic in high assurance environments, especially when combined with implicit typing.

By: A monad tutorial for Clojure programmers (part 2) « On Clojure

A monad tutorial for Clojure programmers (part 2) « On Clojure — Fri, 24 Apr 2009 16:14:37 +0000

[...] part 3, I will come back to the :when clause in for loops, and show how it is implemented and generalized [...]

By: Samuel A. Falvo II

Samuel A. Falvo II — Thu, 16 Apr 2009 00:24:37 +0000

Speaking from experience, and NOT using monad transformers, the ease of use of a state monad is about the same as any other imperative programming language. The nice thing about using the state monad with Haskell, however, is you get the advantage of its type inferencing/checking, which is a significant plus. This prevents you from mixing up your monads, which in turn, results in programs where the logic of multiple parts of a program are kept separate _syntactically_ and is compiler-checkable.

Again, introducing monad transformers muddles the water a bit, but once again, it’s statically checkable. You cannot mix multiple monads without having first declared it first. This might seem like a big burden; in fact, however, it aids greatly in program cleanliness and modularity.

ONCE you wrap your head around transformers.

By: khinsen

khinsen — Tue, 14 Apr 2009 07:56:20 +0000

I don’t think there is a clear yes/no answer to that question. It is possible to write hard-to-read code in any style, including pure functional, and of course also including the state monad.

However, there are a few important differences between programming with mutable state and programming in the state monad. There is no real mutable state in the state monad, so in terms of concurrency state monad code is definitely purely functional. But most importantly, the state monad is just one tool in the functional programer’s toolbox, and it should be used only where it makes the code clearer. This is the case for algorithms where keeping track of a state is required anyway, a classical example being labelling a graph. Programmers who use the state monad as a convenient way to write imperative code in a functional language will most likely produce bad code. As a rule of thumb, I’d say that if you start implementing loop constructs in the state monad, you are probably going too far.

By: Anand Patil

Anand Patil — Mon, 06 Apr 2009 17:58:08 +0000

A quote from Rich Hickey that I like is ‘mutability is the new spaghetti code’: if you can mutate an object, you can produce ‘action at a distance’ that seems convenient at first, but in the end makes your program logic harder to follow.

I understand that the state monad makes it possible to make your code seem stateful, but keeps it possible to analyze it as a purely functional program. But does that convenience drop you back into ‘the new spaghetti code’, or are programs with the state monad easier to follow (for human coders) than programs with genuine mutability?

By: khinsen

khinsen — Wed, 25 Mar 2009 08:55:16 +0000

Combining monads using monad transformers will be the topic of part 4. It is not a general possibilty; you can’t combine any monad with any other one, but it covers a lot of situations that come up in practice.

Of course, nothing prevents you from using one monad within another if that’s what your problem requires. For example, you can well have a “domonad writer-m” and inside one the right-hand-side expressions put a “domonad maybe-m”.

Monad transformers are different in that they produce one monad that combines the aspects of two (or more) individual monads.

By: Puzzler

Puzzler — Tue, 24 Mar 2009 18:23:15 +0000

Yes, much clearer. But now I’m wondering whether it is possible to combine the behavior of two monads in one body of code. For example, what if you want to be able to “write” some lines, and on other lines get the “maybe” behavior, and on other lines get the “identity” behavior?

By: khinsen

khinsen — Tue, 24 Mar 2009 09:31:29 +0000

I have added a concrete example: the Fibonacci function with a tracing system for recursive calls. I hope this makes it clearer!

By: Puzzler

Puzzler — Mon, 23 Mar 2009 19:42:01 +0000

I’d love to see a concrete example of using the state monad to do logging. I can’t quite get it from your description without seeing it in action, because it sounds like you can only do a write command in a place where you’d typically do a let, rather than at an arbitrary point in a sequence of statements.