it has to be this way. Phenomena like this represent possible failure points, and it’s a good technique in programming to try to eliminate or control such potential failures. If you want a simpler example, consider looping through a list to compute some result—do you write an explicit for-loop or do you instead use a higher order function? The latter has fewer moving parts.... In general, we’ll often ask the question: what do we actually need, and can we express it in a straightforward and safe way? There are also some elements of BDD-ish thinking here too: for example, we’ll be asking “What’s the simplest thing that would work,” without committing ourselves to an existing framework. Let’s consider the questions in the context of a concrete application as a guard against getting too abstract, and as a source of examples. How about this: a distributed to-do list tool, which allows users to maintain a set of lists, add and remove items from a list, and mark items as completed, maybe with some advanced features like sharing a list between several users. This is something of a test application for several Javascript front-end libraries, too. Finally, don’t expect too many answers in this article. My main goal is to ask the questions and see what your response is! Towards a Functional Approach We’re going to put data first, over process or tradition, and see where it leads us. Firstly, the bits we can’t easily change—the Http protocol and how it is used by browsers. Browsers make requests to a host with a certain path string and maybe some parameters. Typically, they will also submit session information too. The expectation is that the server will return some text or Html for rendering, or possibly some javascript code to execute. (Let’s ignore static things like images for now.) Somehow, the app on server will decode the request into something more structured, run some code, and then return a piece of text. Typewise, we can start thinking of String - String for the type of the transaction, or being a bit more precise or informative with Request - Response, where Request represents a path and parameters with the relevant Http verb (eg GET, DELETE etc.), and Response can contain various bits of meta-information like mime type in addition to the raw response. Html is (or is generally intended to be) stateless, and this is reflected well in the simple type above. However, session information can sometimes muddy the water and make the requests context dependent. For example, it could depend on whether someone is logged in or not. There will also be real-world side effects: doing a DELETE of some resource will affect the outcome of any GET of the same later. A simple way to encode this context dependency is to refine our type to (Sessionable server, Monad server) = Request - server Response, that is, explicitly requiring the transaction (well, the generation of some response given a request) to be a monadic action and following the usual monad rules and conventions, plus supporting various session operations. PragPub January 2013 9