From: "andrew cooke" <andrew@...>

Date: Fri, 11 May 2007 09:58:46 -0400 (CLT)

Recently there has been discussion on the Erlang mailing list about "monads". Monads were popularised by Haskell - they are defined by type constructor (something that "makes" monads) and two operations: unit and a binding operation. And they are used to impose a sequence on a set of operations. This is necessary because Haskell is lazy - the order in which functions are evaluated is not the order in which they are defined in the program - and so some kind of ordering is needed when doing things that involve mutable state (for example, asking the user to enter data should come before reading input!). OK, but what has this got to do with Erlang? Very little - Erlang is an eager language and evaluates functions in a nice, easy-to-understand way. So there is no need for ordering. Monads provide more than ordering - it it turns out that the "monad API" is quite fundamental, and can be applied to many different scenarios. So it provides a unifying concept across lists, optional values, exceptions, etc. But, again, the Erlang discussions have nothing to do with this. In fact, the Erlang discussions are not about the semantics of monads at all. The posters are purely concerned with the "syntactic sugar" that Haskell added to support monads. This lets you write code in an "imperative style" - it gives the appearance of mutable values. So what is really happening? Partly this is a social phenomenon - it's a lot more acceptable to say "we need monads" (which are a "cool" concept) than to admit that you want to program using a style unsuited to the paradigm supported by the language. But that's not the whole explanation. This is clear from Haskell, where the monad syntax is not used for "most" code. Examples of elegant code, which are abundant for Haskell, use Haskell's succinct and powerful "fucntional" syntax. It, in fact, a "newbie error" to write a program entirely using the monad-specific "do syntax". So it's clear it's possible write clear, elegant programs in a functional style (even when the monad syntax is available). Why don't people want to do this in Erlang? Part of the answer to that question is, again, social. Erlang is growing rapidly from a small user base. So there is a lot of pressure from incoming programmers, accustomed to procedural programming, who want what they are accustomed to having. But part of the answer is also found in Erlang's poor support for common functional programming idioms. Take the following line of code, which I wrote earlier today, as an example: NonBlankLines = filter(compose_1(fun util:not_/1, fun util:is_blank/1), Lines). This filters a list of lines, discarding those which are not blank. It could just have well have been written as: NonBlankLines = filter(not is_blank, Lines). In other words - Erlang *punishes* you when you write code in a functional style. It requires you to add a whole pile of pointless noise. For example, in the code above: - compose_1 is necessary because Erlang does not have a syntax for composing functions. All I want to do is join two functions together, so the first processes the output from the second. This is a basic building block in functional programming and could be supported by simply writing the two fucntion names together ("not is_blank", as in the second version). - not_ is a utility function necessary because there is no way (that i could fine) to refer to the inbuilt function "not" directly. So "not_" is defined as "not" just because inbuilt functions are, in some odd sense, broken. - namespace:name is necessary because even though i have imported these functions the namespace is *still* necessary when referring to a function directly. There's no ambiguity - I could have used "is_blank" alone (without "util:") if I just wanted to call the function. This strange restriction is only necessary when referring to the function's name. - fun is necessary to flag functions. Again, this is pointless - when I call a function I don't need to specify what it is. Erlang code religiously follows a naming convention that separates functions and variables (by case of the first letter) so this doesn't even require any type analysis. It's crazy. The parser is brain-dead lazy. No wonder people don't "get" it and keep trying to turn Erlang into C or Java. Andrew