It seems like an especially useless abstraction to be making if you only have that one example, and you're coming from an imperative background (like perl), which is quite a lot like working in the IO monad all the time.

If you'd like to see other examples of monads and what they're good for, I highly recommend starting off with a look at Parsec, which is a library for parsing implemented in Haskell (and then reimplemented in a bunch of other languages). A simpler decent example is the list monad, which gives you what are essentially list comprehensions, or what computer scientists call nondeterministic computations.

Also, having the monadic abstraction lets you write algorithms which are generic over a wide class of monads, and then apply those at specific monads for a variety of effects.

Let me give a somewhat involved example, so you can hopefully get a sense for what I mean. A friend and I wrote an L-system fractal generator which was nondeterministic, in the sense that each rule gave a list of possible expansions for a symbol, and it enumerated all possible expansions of the L-system. For display on the screen however, we wanted to choose a random one. Generating the whole list was wasteful, so rather than do that, we replaced the lists of rules in the input to the algorithm with computations in a random-generation monad which would emit one of the results in the original list at random. Since the expansion algorithm itself was generic over monad, only the input to it had to change, and we had a randomised L-system generator.

Similar changes to the input could be made to incorporate state transitions into the expansion of the L-systems (or even continuations, if you're crazy), all without changing the code that actually does the expansion.

So what are monads really? They're embedded domain specific languages which have been constructed to conform to a particular basic structure so that various control structures and generic algorithms can be shared across those embedded languages. There are lots of good examples in Control.Monad. For instance, forM/mapM is essentially a for-each loop which works in any monad. This saves you the trouble of implementing a new for-each loop in every new EDSL you write.

That is, when you're implementing your EDSL, if you just bother to implement return and bind, you immediately get a nice API of control structures for free. Implement mzero and mplus, and you get an instance of MonadPlus, which gives you a bunch more.

By encouraging people to write and use EDSLs (which are essentially just really good APIs) you encourage people to write code which is closer to the domain, and hence easier to think about. I/O is a red-herring -- I/O is handled by a monad in Haskell not because it's absolutely necessary that it be handled by a monad, but because it's possible, and so you get all the basic control structures for I/O from that same monad library for free.

It seems like your entire article would make a lot more sense if every instance of the word "monads" was replaced with "the IO monad". There are other monads, you know.

Yes, I do know, but please think about where you are reading this and the target audience, as well as my admission to being a 'failed' Haskell programmer. You should not expect deep and authoritative discussion on Haskell in this environment :)

It seems like an especially useless abstraction to be making if ... you're coming from an imperative background, which is ... like working in the IO monad all the time.

That was and is pretty much exactly my point. I'm aware that the bits I've elided make the statement much less definitive than I did, and within that lies the power of the monad abstraction, but that brings me back to my final question above, which can be paraphrased as: Do I, as a jobbing programmer need that power. It may be a endlessly fascinating subject for the academic/language designer, but does it really give the working stiff something that he does not already have in other languages.

Isn't there a dichotomy between these sentances from your first and last paragraphs?

• "(In particular, the IO monad is primitive in Haskell by necessity, but it's the only monad like that.)"
• "I/O is handled by a monad in Haskell not because it's absolutely necessary that it be handled by a monad, but because it's possible,"

---

From this point I'm going to have to resist the temptation to get drawn into arguing about the efficacy and effectiveness of Haskell (here). This is the wrong place, and I am not qualified. I've already allowed myself to over-extend my reach, and I'll probably regret doing so. But I'd be willing to continue and would relish the opportunity to learn) off-post via email, but not here.

However, your arguments above remind me of a post I made some time ago. Please do not take offense. Nor think I am aiming the first line (or most of the rest of it) at you. And definitely ignore the context in which it was posted. But...there is one bit that I think is applicable, though even that isn't worded quite right for application in this context.

...and succeeded in re-creating your system using theirs, will you be in a position to counter their objections to your system, in their own terms.

Only then will you have the ammunition with which to prove the veracity and accuracy of your system, in a way such that they can accept it.

What I'm trying to get at here is that if you 'buy in' to the whole Haskell experience--from the efficacy of Hindley-Miller and functional programming, and purity up--then everything you say above, and all the deep discussions and treatise and papers in the Haskell world may (probably) make sense.

But, if you are coming from a long and deeply imperative background as I am, and with respect, the vast majority of the worlds programmers are, then without the mathematical grounding to fully appreciate the full implications of HM, and the category theory underlying monads, it does seem like, as you put it above, " an especially useless abstraction".

The problem with the rich and extensive set of information available on Haskell, and monads in particular, is that for the most part, it assumes a deep understanding of those underlying (and often obscure) mathematical concepts. It is often also somewhat pejorative and condescending ("... or what computer scientists call nondeterministic computations.") of those that do not come from that background.

I'm not offended by that. It may well be true that I am either too old and set in my way, wrongly educated, or just too stupid, to ever make the journey of enlightenment required. Required to allow me get beyond the feelings of frustration when I encounter something (in Haskell) that seems clumsy, over-complicated or outright impossible, when I know that I could do that same thing in any of a dozen other languages in my sleep.

You'll note (or rather I'm going to do it for you), that I never said that Haskell didn't need or benefit from monads. Indeed, I said the exact opposite. And when I asked "Are monads worth [the bother]", I was doing so from the perspective of someone who has written hundreds of programs and 10s or 100s of thousands of lines of code (guesstimate!), without ever once needing 'monads'.

And to explain that monads are necessary "because they ensure referential integrity", isn't enough. Because I've written those same number of programs and lines of code without needing that either. And that's where the quote from my old post above comes in.

Until I can understand how the provision of the same facilities Haskell has would benefit my programs in Perl (or C, or Java, or ...), then it's just not possible to see beyond the argument that Haskell only has those facilities because Haskell needs them.

And Haskell only needs them because it makes certain (dogmatic) decisions about the need for purity, referential integrity, strong typing and provability. And all of those are just too easy to dismiss as unnecessary and/or non-beneficial.

(I can see) There are several aspects of Haskell that are desirable, but as a language it is impossible to have those bits without taking all the rest, and the rest imposes such burdens upon the development and thought processes, that I have to question whether they are worth it.

Don't misunderstand me. I know (for example) that proficient Haskellers tend to win against-the-clock programming competitions with unerring regularity, almost to the exclusion of all other languages. So i know that, in the right hands, Haskell very much challenges and often surpasses Perl at it's own game in the programmer productivity stakes. But, how many expert Haskellers are there?

And how many of those programmers earning a living on a daily basis in other languages have the (maths theory) background and nouce to make the transition to using Haskell? And if they have to acquire a good understanding of category theory and type system theory and dog knows what else in order to see the benefits of the transition to using Haskell, how many of them are going to have the incentive to try?

Until someone can explain its benefits to them in their own terms, the incentive to learn enough to understand the concepts in Haskell's terms, and those of functional programming purity, are minimal. Mostly just curiosity, which is easily 'cured' by work pressures, or condescension, or apparently self-describing, self-confirming 'belief' systems.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

If you'd rather read that with proper spacing, see: http://programming.reddit.com/info/1xlxp/comments/c1xoho

Oops, all the spacing got squashed out of that. Oh well.

You might like the Clean language more, where I/O is done with unique types. And then, once you get tired of carrying this "world parameter", you might say to yourself, "Why don't we tuck this boilerplate away into a function, so that we don't have to mess with it all the time?" Bingo, there's the usefulness of monads.

And to answer the OP's question, there is essentially no reasonable reason why anyone would use monads in Perl. Besides the fact that Perl's syntax makes it heavyweight and messy, its lack of static typing makes it hard to program in a functional manner.

Unfortunately, I/O is probably the worst example of a monad there is. The next worse example is the state monad. The "Maybe" monad is much better example, especially for beginners.

As I hope I demonstrated above, I understand what monads, and the IO Monad, are and do.

The problem I have with monads, is not the name, or their obscure math derivation, or using them (much, though I admit I probably couldn't derive my own any time soon).

The problem I have with them, is the need for, and the benefits of, having them at all.

They are, emotionally, just a way of concealing the fact that Haskell programs contain code that has state, has side effects and is procedural. Technically, they are a way of indicating to the compiler which functions have no side-effects and can therefore be safely re-written at compile time; and which aren't. And that's makes them a really awkward way of setting a flag.

It would be so much easier to simpler to have a keyword that could be placed at the top of a module or even half way down that says any definitions above this line are purely functional and anything below it is procedural code that has side effects. The 'monadic code' then just becomes normal procedural code that carries an implicit 'world state' from one step/statement to the next; it could be coded in a normal, procedural style with loops and state and side-effects; and without all that faffing around that monads introduce.

No need to (badly) re-invent all the standard procedural constructs--like try/catch et al.

At this point, I'm gonna stop, and ask you to email me (address on my home node) if you feel like continuing this, because this has become about me and Haskell (and Clean--which I do like more, though it lacks the community and available tutorial information that Haskell has. Eg. A search for lang:clean on google codesearch finds zero hits!), and has ceased to have any relevance to Perl. I'd enjoy the rebuttal :)

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

They are, emotionally, just a way of concealing the fact that Haskell programs contain code that has state

Rephrasing to mitigate the emotional stress: monads encapsulate effects. They aren't there to conceal in the sense of deception, but rather in the sense of information hiding.

I agree with the other poster who said the IO monad's the poorest one to look at, because I agree with you when you said a Perl program is in a(n IO) monad. But that's trivially true; the value comes when you look at the richness of different monads, and when you can take your code and separate functions out of it into those that really are pure and those that can be made to fit in monads a, b, c.

Here's a simple example.

ruleSubName :: RuleParser String
ruleSubName = verbatimRule "subroutine name" $ do
    twigil  <- option "" (string "*")
    name <- ruleOperatorName <|> ruleQualifiedIdentifier
    return $ ('&':twigil) ++ name
[download]

This is part of the Pugs parser, the code to parse out the name of a sub. Inside the RuleParser monad, sequencing means "demand the following parse to work". But it also means take care of bookkeeping (source code position, name of what we're trying to do for use in error messages in case we fail). If a parse fails, the associated further bookkeeping is automatic. Here we say "first of all, look for a '*' string, but it's okay if we don't find it". The function string is monadic; if it failed then the function 'option ""' works much like a try/catch and provides the fallback. Anyway, now twigil is either "" or "*", and the position has advanced by 0 or 1 columns.

Now we try to parse a "name". We try a first parser, ruleOperatorName, and if it fails, ruleQualifiedIdentifier. If that one fails too, ruleSubName will fail. The actual behavior of that failure depends on who called us; if they were ready for us to fail (for example, by modifying us with "option" or "<|>") then a different parse might result higher up. Rewinding the position happens automatically, for example if we had already consumed a "*". But if not -- if we're in part of the Perl 6 grammar where the only conceivable term is a SubName and one could not be obtained -- then the user will get an error message saying Pugs was looking for a "subroutine name".

What I'm hoping I've shown is that all these bits of pieces of combining small monadic functions are common to the domain of parsing. Haskell isn't being deceptive in not making me put try/catch blocks over every line. It's encapsulating very specific and repetitive functionality.

I think one great difficulty in understanding monads is they take "if you look at it that way" to the extreme; and Haskell programmers often look at problems in surprising ways. Since parsing is a very practical problem, and familiar to Perl programmers at that, it's a good monad to learn with.

They are, emotionally, just a way of concealing the fact that Haskell programs contain code that has state, has side effects and is procedural.

I'd reword that a little differently. The type system loudly proclaims to everyone that these particular functions are contaminated by state and side effects, so by-golly you'd better don the bio-hazard suit and procede with caution.

it could be coded in a normal, procedural style with loops and state and side-effects; and without all that faffing around that monads introduce.

No need to (badly) re-invent all the standard procedural constructs--like try/catch et al.

I think there's probably a large subjective element in choosing a favorite programming. Some people like cats, others like dogs. When I first encountered Haskell, my initial reaction was, "Yes! This is how programming was intended to be done". I no longer needed to faff (?) around with side effects willy-nilly everywhere.

It sounds like you've had the opposite reaction. No harm, no foul. If you don't like broccoli, there is no sense in feeling bad just because others rave about it. And anyone who nags you about the health benefits of broccoli is a bore.

Haskell programmers truly think it is a better way to program. No apologies. (Heck, maybe we're just crazy). And some of us think that Haskell doesn't even go far enough.

I don't view monads as just a way of telling the compiler what effects I'm using (it doesn't really do that anyway). It's a way of tell *me* (or someone else reading the code) that this is effectful code, and that care must be taken.

You may be interested to know that Haskell did not always use monads for I/O. This paper describes three alternative, purely functional methods for implementing I/O in Haskell that were used before monads:

http://citeseer.ist.psu.edu/30726.html

It is also important to note that monads not special things wired into the compiler. They are built using normal Haskell code and live in the standard libraries.

It is quite possible to write real programs in Haskell without using any monads. Of course, you would probably just reinvent them without realizing it.

On the Expressiveness of Purely Functional I/O Systems

It's possibly a very interesting paper, but all I can find online are citations and references--which means it might as well be printed in a 9 point font on the Moon for all the accessability it has.

It is also important to note that monads not special things wired into the compiler. They are built using normal Haskell code and live in the standard libraries.

That sounds promising. Care to show an example of how to read from stdin and write to stdout without using a IO Monad? Or just perform an question and answer session interactively without them/it?

It is quite possible to write real programs in Haskell without using any monads.

Again, care to post an example that can be compiled with GHC v6.4?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

On the page I linked to, in the top-right hand corner, there are links to the paper in several different formats.

The paper includes a bunch of examples. As far as I know, there is no fundamental reason why those libraries could not be used with a modern version of GHC.

A simple experiment you can do to see what non-monad I/O is like is to use the interact function.

main = interact yourFunction
[download]

yourFunction is a pure function which takes a lazy list of Strings (which are gathered from stdin), and returns a lazy list of strings (which are written to stdout).

For some examples, (such as interactive questions using stdin/stdout) check out this page:
http://cod3po37ry.blogspot.com/2007/02/more-on-haskell-io-and-interact.html

Although interact is currently implemented in the IO monad, I believe it pre-dates monadic IO.

...all I can find online are citations and references...

What happens when you click on the PDF link in the light blue box in the upper left hand corner? What about this link instead?

Wow! A rave from the grave.

First off, thank you for the links. I've only browsed most of then so far, but they will make for interesting reading over time.

If I am not wrong, FP-people say that absence of side effects simplify proofs of correctness (wrt specifications), not that proofs of programs with side effects are impossible.

Maybe they do, but not in most papers I've read. When I read a formal proofs paper that deals with a real world problem rather than isolated, mathematically pure problems--like incrementing a number or multiplying two numbers together--then I (and other programmers), might to start to sit up and take notes.

What do I mean by a real world problem? Let's start with something really trivial. Command line filter programs. Say wc and tee. Show me (and explain) a formal proof for one of these programs. How it will handle taking input from a local disk file; or a remote disk file; or via pipe from another program; or from the keyboard; and ditto for the sink; and still do its job.

But they never do that. Somehow, they manage to persuade someone, somewhere to pay them public money (it has to be public, because no one would fund this stuff privately), to write papers on how to "prove" a computer can successfully increment a number. And they come up with

Let's try it on a trivial example. Informally, the specification is to increase the value of integer variable x . Formally, we face a problem: we are given no way to relate the final value of a variable to its initial value. We have to use a trick: introduce an extra variable, not part of the state space, to carry the relation. We write

∀X� {x = X} S {x > X}

meaning: whatever x may have been equal to at the start, it is greater than that at the end. For S we might propose the assignment x:= x+1 . To prove it correct, we must use the assignment rule {substitute e for x in R } x:= e {R} In the example, this means

{x+1 > X} x:= x+1 {x > X}

The precondition is not what we want, so we now use the consequence rule (∀σ� A ⇒ P) ∧ {P} S {R} ∧ (∀σ� R ⇒ Z) ⇒ {A} S {Z} where σ (the state) stands for all variables. In the example, this means we must prove

∀x� (x = X) ⇒ (x+1 > X)

which is now a simple theorem of ordinary logic. All that, just to prove the obvious!

No shit Sherlock. All of that, to prove $i++? And that doesn't even handle the case where $i = 2147483648;. They'll undoubtedly determine that the outcome of incrementing that to be 2147483649, but the reality is, on 32-bit computers systems that it might be. Or it might be -1.

But that formalism above won't consider the case of what happens when you increment a signed integer across its register size boundaries, because mathematicians live in a theoretical world of Real and Natural (who knows how many other obscure theoretically infinite, mathematically convenient) number domains, and none of them pay the slightest consideration to mundane realities like register sizes and word lengths.

Now lets look at what they come up with for multiplying two numbers. This is the modern, advanced, abbreviated, compacted version. See the last linked paper above, page 9 for the unabridged nightmare:

x' = x y�: s:= 0; s' = s + x y; x:= s

s' = s + x y�: if y=0 then ok

else if even(y) then (x:= x 2; y:= y/2; s' = s + x y)

else (s:= s+x; x:= x 2; y:= (y–1)/2; s' = s + x y)

I won't pretend to fully understand that, so I'll ask a few questions: Does it handle register overflow? How about one or both inputs being #NaN? Or either or both being one of the two flavours of infinity?

I'm not mathematician, but take a closer look at the case above where if y=0 then ok. According to the paper, "ok is the identity relation and then later on "The empty (do nothing) program ok is the identity relation". Que? The way I read that, if the second (or one of?), the inputs to multiplying two numbers is zero, we do nothing! So-orry, but my schoolboy arithmetic tells me that anything times zero is zero--not throw your arms up in disgust and do nothing.

Bad rhetoric

I realise that the author is a much clever person than I am, but right from the start of this paper there are a bunch of things that just don't ring true.

Formal programming methods allows us to prove that a computation does what its specification says it should do. More importantly, formal methods help us to write specifications, and to design programs so that their computations will provably satisfy a specification.

This is analogous to the use of mathematics in all professional engineering: civil engineers must know and apply the theories of geometry and material stress; electrical engineers must know and apply electromagnetic theory.

So why don't software engineers know and apply a theory of programming?

I've broken that into three paragraphs. The first is the sales pitch. A broad-termed, theoretically desirable goal. A panacea. A magic bullet.

The second paragraph is supporting argument.

• Argumentum ad verecundiam

  in all professional engineering

  Most civil engineers to not use theories of geometry and material stress. They use tables.

  If this member is at this angle carrying this load, it will need to be--scan across for the angle, scan down for the load--this strong. And looking that up in the manufacturers tables for (say) steel girders or reinforced concrete lintels, including the statutory increment for safe working load for this type of construction, it will need to have this cross-sectional area. And that means part number xyz. Of course, for the most part these days, they'll feed their proposed design into a finite element analysis simulation, and increase the strength of the members until they eliminate any "hot spots".

  And an electrical engineer will rarely need to remember, let alone actually calculate any "electromagnetic theory" once he's left college. It's mostly just a case of picking the appropriately rated parts from the manufacturers catalog. Sure, someone somewhere had to design those parts, but I guarantee that not one single rating was arrived at through mathematical processes. The ratings are arrived at by testing--probably to destruction--and then applying a substantial "fudge factor" to indemnify the manufacturer against failures when close to the limits.

  As an example, there is a whole sub-culture of computer geeks that get their jollies by seeing how far the can push the clock rates of cpus beyond the manufacturers ratings.

• Cum hoc ergo propter hoc.

  The paper postulates that because of the use of mathematics in all professional engineering, all programs should be written using the theories of mathematics. And all programmers should be mathematicians.

  Except, as I've shown above, the cum hoc is false, hence the ergo doesn't.

To date, in all the sources I've read, mathematicians completely miss the point about engineering.

Engineering is not about specifying products, from the ground up, in logically provable, theoretical terms. Engineering is about about assembling a collection of standard parts, to meet a set of requirements, in a timely fashion, for the lowest cost. And whilst some of those requirements will be measurable in ISO units: speed, weight, strength etc. Another bunch of requirements will be ethereal things like looks, feel, affects on the environment, impact on the view, life-time costs, built-in obsolescence, usability, desirability, etc.

And the impact of those ethereal elements on the success of products becomes ever more important. Take the success of things like:

• the mediocre technical capabilities of the iPhone:

  but boy does that interface ever make for good TV ads.

• the heavy, slow and expensive Toyota Prius:

  it's not that much more fuel efficient than a modern say 1.2 litre VVT petrol engined four seater, and far less fuel efficient than a modern, common rail 1.4 diesel engined equivalent.

  The secret of its success? You cannot mistake a Prius for anything else. And there are no 200+ HP, 16-valve, turbo charged variants of it. So when you pull up along side the red carpet in it, amongst all the 40' long, gas-guzzling stretched limos, no one is in any doubt that "you care".

  Even if you did just fly half way around the world in your private jet to attend.

Engineering is not theoretical

Engineering is not about proving that the product complies with theories. It's about satisfying a few theoretically quantifiable requirements, and a whole bunch more unquantifiable ones. Read about the construction of the Millau Viaduct. A very small part of the effort involved the solving of well-known formulae ensuring the strength of the beams, cables and towers. A larger proportion was to do with the logistics of constructing those huge skinny towers in a "continuous pour", running the cables and manoeuvring the decks into position.

But a far larger proportion of the effort was involved in minimising the impact of the construction on the environment; ensuring the aesthetics of the final construction; engendering national pride in the French psyche.

Very few if any software projects have anything like these logistics and emotional criteria to deal with.

Dark Ages

In engineering terms, the software industry is currently, roughly equivalent to the 16th century cathedral building industry in terms of sophistication. Like them, we build each construction from scratch, individually, to fit its landscape. Each building block is carved to fit its individual neighbours. We build the infrastructure just as thick as we think it needs to be, and if it starts to fall down when we're half way up, we build it thicker.

In metalworking terms, we may no longer need to start by extracting the raw metal from the ore, but we are still at the point of fettling pieces of standard stock to manufacture individual components.

Software development has as much to do with "engineering" as does cookery. Indeed, cookery is now routinely done on a mass production, engineering scale, and software hasn't even come close to achieving that.

I sit here at this computer with a dozen or more languages installed and, despite the theoretically provable, analysed and documented to death nature of a simple sort function, there are probably 2 or 3 dozen implementations of quicksort in the various libraries on my system. And they probably all have bugs.

Until we start constructing programs from standard parts, the terms 'software' and 'engineering' do not belong in the same sentence. And I don't mean standard libraries of functions, or extended class hierarchies.

The former come in huge great globs of disparate facilities all lumped together into single linkable, statically or dynamically, chunks. If I want to replace a single function, be it sort() or strcmp(), I have to replace everything else it's library contains also. And that means re-testing everything.

And the latter is source code. The approximate equivalent of blueprints. To replace the implementation of a single class means rebuilding the program (and every program) that uses it. And that means re-testing everything from scratch.

More craft than engineering

Until OSs provide us with a catalog of standard parts, specified in high-level, generic terms, that we can replace individually, and assemble together, at runtime, into higher level sub-components; test in the abstract and then assemble those into higher level components still; software development will remain more craft than engineering.

And formal methodologies will remain a theoretical pipe dream beloved of academics but largely ignored by the industry just as it has, as pointed out by the paper, ever since Hoare first proposed it in 1969.

It took metalworking nearly two millenia to move from the bronze age to engineering. I doubt that software will take quite so long, but we are currently still somewhere in the Dark Ages and (IMO) Hehner's optimism: "I am optimistic that Kieburtz is right, that the use of formal design methods is just around the corner." is still wildly misplaced.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."