Contents

Talk:Monad (functional programming): Difference between revisions

Revision as of 12:21, 27 October 2009

Computing B‑class

This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles B This article has been rated as B-class on Wikipedia's content assessment scale. ??? This article has not yet received a rating on the project's importance scale.

This is the talk page for discussing improvements to the Monad (functional programming) article. This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Article policies Neutral point of view No original research Verifiability

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Archives: 1, 2

Computer science B‑class Mid‑importance

This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer scienceWikipedia:WikiProject Computer scienceTemplate:WikiProject Computer scienceComputer science articles B This article has been rated as B-class on Wikipedia's content assessment scale. Mid This article has been rated as Mid-importance on the project's importance scale. Things you can help WikiProject Computer science with: Here are some tasks awaiting attention: Article requests : Requested articles/Applied arts and sciences/Computer science, computing, and Internet Cleanup : Computer science articles needing attention Computer science articles needing expert attention Copyedit : Computing Expand : Computer science Infobox : Computer science articles without infoboxes Maintain : Timeline of computing 2020–present Photo : Find pictures for the biographies of computer scientists (see List of computer scientists) Computing articles needing images Stubs : Computer science stubs Unreferenced : WikiProject Computer science/Unreferenced BLPs Project-related : Tag all relevant articles in Category:Computer science and sub-categories with {{WikiProject Computer science}}

Even for someone with a bachelor's in computer science/informatics, this information is prohibitively difficult to understand. Yes, it is true that Monads are a difficult concept. However even if one can understand everything this article is saying (bind/>>=, return), the big picture just isn't presented in this article. It is full of convoluted examples.

Some important questions that need to be addressed early and in their own sections:

• Why do people think Monads are so important? What wouldn't you be able to do without Monads
• What are the thing Monads can be used for? e.g. common examples: IO, nondeterminism via lists, etc.
• Do Monads have analogs in other functional languages? LISP?
• In the definition of a Monad, is the overlay of types one-to-one? For example, is it okay not define Monad(Type) for some Type? Or must it work for all types Type?
• This article should use less single-letter variables and more variables with actual names. This is not abstract math that needs tons of footnotes to define variable meanings, even though it is linked to category theory.
• There is always a tradeoff in defining something. What advantages does defining a type as a Monad give one, as opposed to just defining a generic type-constructor. What are the nifty things one can do? For example, what would happen if Bind did not exist? If Return did not exist? Without return, there would be no way to link the new monadic types with the previous types you've defined... right? Or maybe wrong...? What about Bind? —Preceding unsigned comment added by 18.202.1.175 (talk) 23:52, 4 May 2009 (UTC)[reply]

Someone should really add this article to some list of articles needing revision, or email the Haskell mailing list.

This is actually the same as Monad (category theory). These should be merged. —Ashley Y 22:19, 2004 May 31 (UTC)

They're not really the same thing: an explanation of Haskell's IO monad doesn't belong in an article on category theory, and a detailed explanation of monads in category theory isn't relavent to the average Haskell programmer. In addition, many standard Haskell monads aren't strictly speaking monads at all. I think it's probably best to keep the articles separate. Cadr 22:28, 31 May 2004 (UTC)[reply]

Which Haskell monads are not monads in the CT sense? —Ashley Y 09:58, 2004 Jun 1 (UTC)

The IO monad is one example (see [1]). Cadr 11:08, 1 Jun 2004 (UTC)

It's not clear, actually, since the difference is only visible with the 'seq' function, which is considered slightly dubious anyway. More importantly, these are Haskell's monad laws that IO may or may not be properly living up to: the sense in which "monad" is used in Haskell is precisely the CT sense.

If you think this should be a separate article, rename it "Monads in functional programming", rather than the () notation which suggests that it's a separate sense of the word.—Ashley Y 02:49, 2004 Jun 2 (UTC)

OK, but it's still the case that the two articles cover very different information. I'm fine with it being renamed to Monads in functional programming. Cadr 14:15, 2 Jun 2004 (UTC)

Rename (from "Monad (functional programming)") done. —Ashley Y 23:27, 2004 Jun 2 (UTC)

Er, the first sentence of the second para (and possibly more) looks like a copyvio from http://nomaware.com/monads/html/introduction.html#what --- I don't know the topic well enough to rephrase to eliminate this. Could someone who knows the topic look into this? thanks, jdb ❋ 06:00, 27 Jan 2005 (UTC)

The // causes me no discomfort despite C being my first language. It's really obvious that it is an operator, especially given the text defining it as an operator... at least for me. However I *did* get confused by "par" (is it relevant to learning about Monads? oh no, it's an example taken from electrical engineering that I've seen before; it deserved a comment defining it) —Preceding unsigned comment added by 18.202.1.175 (talk) 23:56, 4 May 2009 (UTC)[reply]

Why is the function ${\displaystyle (x,y)\mapsto {\frac {1}{{\frac {1}{x}}+{\frac {1}{y}}}}}$ called par? --MarSch 11:06, 25 October 2005 (UTC)[reply]

At least that's the function for total resistance of two resistors in parallel coupling. --TuukkaH 16:14, 25 October 2005 (UTC)[reply]

For people used to reading C++ all day, "//" is a very difficult operator name to read. It looks like the start of a comment, and it's almost painful to have to ignore such "comments". Perhaps it could be renamed to "./." or even "///"? Kimbly 02:52, 10 January 2006 (UTC)[reply]

What about "::", "->", and "--"? (and "|", ">>=", ">>" and "++", further down the page.) Like "//", they all have specific, and entirely different, meanings in C++. Beyond C++ and Haskell, you'll find yet other meanings for them. What makes C++'s "//" special enough to avoid?

Besides, it's fairly clear that the examples are not in C++, so i don't see how it could cause more than momentary confusion, at worst. --Piet Delport 04:34, 10 January 2006 (UTC)[reply]

In most grammars, comment signs are special: // and /* in C++, Java etc., # in Python etc., ; in Lisp, -- and {- in Haskell. I noticed I've special-cased them too and skip text in them automatically. C++ programmers are used to << etc. meaning many things because they are overloaded already in the standard and most every language has operator overloading. Of course you can get accustomed to any a syntax, but do we want to make it as hard as possible for people to read this article? It's not like // would be an integral part of the Haskell syntax. --TuukkaH 09:19, 10 January 2006 (UTC)[reply]

Personally, i've been using C, Java, and Javascript for at least a couple of years (with // comments wherever possible; i'm not fond of /**/), but the example still doesn't cause me any discomfort. Besides, even if you limit the symbols to comments, what about Forth (and Forth-like) programmers, who use parentheses for comments (like in English)? The curly brace programming languages are very important and influential, but they're not special enough to start imposing their syntactical meaning on innocent bystanders.

Besides all that, i want to note that // already has an established meaning of "modified/alternate division" in several languages (including Python): something that thousands of people can recognize immediately. This alone should make it an obvious winner over inventions as novel as /// and ./.. --Piet Delport 19:51, 10 January 2006 (UTC)[reply]

I know what you mean, I've had the same problem with people using #or## as an operator, while in Python, shell etc. they are used to start comments. As this page isn't strictly about Haskell, if we want to use Haskell as an example, we could still try to remove unnecessary readability problems from the article. --TuukkaH 05:50, 10 January 2006 (UTC)[reply]

I guess my scam is up. I haven't really used Haskell any significant amount, and I barely understand this monad stuff. I just hoped I might be able to push this article away from the two mistakes so many monad tutorials make—presenting them as "how you do I/O" or completely neglecting to give any intuition to the general concept of a monad. I did my rewrite with a copy of Wadler's "Comprehending Monads" in hand, but since I made so many mistakes I'll tag the article for verification. TuukaH is correct above about the naming of par. Gazpacho 04:13, 29 October 2005 (UTC)[reply]

This page really seems to be more about monads in Haskell, rather than in a generic programming language. The examples given seem to be in Haskell, which for non haskell programmers (i.e. me) are really hard to follow.

Shouldn't this either be renamed to something like "Monads in Haskell" with a link to understanding Haskell, or have the equations written in a common mathematical way?

If I understand correctly, monads are containers for values: for example, a monad value like "Just 5" contains the value 5. The return function "wraps" a value inside a monad, the fmap function allows another function to "look inside" a monad value, and it looks like join turns a value like Just (Just 5) into Just 5, or [[3]] into [3]. A few examples:

return 3 = either [3] or Just 3 -- "Wrap" the value 3 with a monad
fmap (+1) [3,2,4] = [4,3,5] -- (+1) is the incrementor function, and it is allowed to "peek inside" this list to increment everything inside it.
fmap (+1) (Just 5) = Just 6 -- Peeking inside a "Just" value.
join Maybe (Maybe 7) = Maybe 7 -- "Joining" these two Maybe's into one
join [[2]] = [2] -- Joining a listifier with a listifier

Is this clear enough? --67.172.99.160 02:09, 3 December 2005 (UTC)[reply]

Kind of. Monads are types with associated functions (bind (written >>=) and return). These are sometimes containers in a naive way — the List monad and Maybe monad. But monads like CPS "contain" something, but it's not directly accessible in any way. More complicated monads do even crazier things: threaded coroutines can be expressed as a monad. Taking an example from a tutorial site (sorry, can't find the URL), a monad could keep a value corresponding to the remaining number of steps to allow in the computation; when this counter reaches zero, all binds just return the value computed up to that point. None of these are "containers for values" in any sensible way.

I don't think moving to "Monads in Haskell" is appropriate. It begins by describing everything abstractly, but eventually we need to discuss monads in practice. Our choices are limited to Haskell, Clean, and Miranda^TM. Every other programming page just picks a language, so why not here? If another language you know of uses monads in an interesting way and with a different syntax, by all means add it in!

I think the current explanation is fine. In that sense the "cite" tag is inappropriate, but it would be nice to cite some source on monads anyway. --Mgreenbe 10:00, 4 January 2006 (UTC)[reply]

I'm finding the haskell-centricity of this pretty rough to follow too. Unfortunately I don't think these examples are terribly useful in their current form for non-Haskell programmers. The syntax is a little exotic, and it'd be better translated into a less symbol-heavy pseudocode. —Preceding unsigned comment added by 194.73.101.34 (talk) 13:20, 13 September 2007 (UTC)[reply]

To be useful, (I concur that) this article should be relieved of its Haskell-centricity. This problem appears to have been lost or ignored; however the importance of the article itself should give some priority to fixing it. Timlevin (talk) 21:15, 28 November 2008 (UTC)[reply]

I think Haskell-centricity is a good thing. It means the article is talking about a real programming language that you can try out and use, and an appropriate one for the subject, to boot. I don't like pseudocode - pseudocode tends to have its own conventions, which then have to be documented - so why not just use a real programming language? And I don't think it makes sense to use a language like Java, in which monads would not typically be used - besides, not everyone knows Java anyway.—greenrd (talk) 22:00, 28 November 2008 (UTC)[reply]

Indeed. I wonder if we even could replace the Haskell code with Java. Even if it were possible, I suspect that the circumlocutions and monstrosities that would result would impede understanding far more than Haskell examples ever could. --Gwern (contribs) 03:05 29 November 2008 (GMT)

I would like to concur that the article should be stripped of its Haskell-centricity. I think that the points by Greenrd and Gwern miss the point a little. It's not that the Haskell notation should be replaced by some other programming language notation. The idea would be to replace it with something like standard mathematical notation in key parts. Not that there can't be Haskell examples, but it would be helpful to make it clear when you are talking about Haskell, and when you are talking about monads as abstract things. So, for example, axioms about monads should be presented in mathematical notation and not in Haskell notation, but it would be great to present examples in Haskell notation. By comparison, in an algorithms book we give the graph theory background using mathematical notation, and then we give the algorithms themselves either in pseudocode, or in a particular programming language. It would confuse things to try to present axioms about bi-connected components, for example, as C source code. Similarly here it obscures the presentation of monad axioms to present them in Haskell. I'd urge that the page be reviewed and a distinction made between the mathematical framework, the examples, and the program constructs, and appropriate notation used in each place. --Rpgoldman (talk) 22:44, 15 April 2009 (UTC)[reply]

The cleanup tag really only refers to the fact that the first line is not rendered as the following lines are, and despite my attempts to fix it, it stubbornly remained the same... perhaps this is trivial, but still visually not pleasing. —The preceding unsigned comment was added by Laddiebuck (talk • contribs) 02:52, March 2, 2006 (UTC).

The rendering is different because the line doesn't contain any non-standard characters, and is thus rendered in HTML instead of LaTeX. If you set your user preferences to "always render PNG", all lines will be the same. —donhalcon^╤ 03:03, 2 March 2006 (UTC)[reply]

I have adjusted the markup to use <code> tags instead of <math> tags and HTML entities instead of PNGs. Should look ok now regardless of settings. —donhalcon^╤ 03:34, 2 March 2006 (UTC)[reply]

The article states that "Since the bind operator is non-associative, this constrains the sequence of execution." Is this really correct? The monad laws require that bind be associative, and the sequencing effect is due to the non-commutative properties of the bind operator. Chuan-kai Lin 17:26, 3 April 2006 (UTC)[reply]

I agree. I changed it to read "Since the bind operator is associative and non-commutative, this constrains the execution into a sequence." Because of associativity there is no hierarchy and because of lack of commutativity the operations must act in the given order. --TuukkaH 06:21, 4 April 2006 (UTC)[reply]

Except this isn't correct. Using the continuation monad, one can have the sub-expressions to "bind" executed in whatever order you want, even in non-deterministic fashion if one so desires. Fortunately, it appears that this text has been removed Obscuranym (talk) 18:32, 4 December 2008 (UTC)[reply]

I rewrote large sections of this article because I cited it for someone who wanted to know what monads are, he told me it didn't make any sense, and I agreed. Mainly, I made it less heavy on mathematical formulas. It's now heavy on Haskell, but I think that's appropriate because Haskell is the main promoter of monads, and this lets people download a Haskell system and try the code. Gazpacho 03:59, 9 May 2006 (UTC)[reply]

I don't think this was a good idea. Mathematics is universal across languages. Haskell is not. Perhaps a little bit of explanation of Haskell's syntax would be in order, or else just use pseudocode. Also, since you do say that there exist formulations in Scheme and Perl, perhaps a reference to those formulations would be nice. The section that existed previous to your edit which defined for instance the bind operator is much more clear than the current version. Please re-add a section describing the notation used, because unless you already know Haskell, it doesn't currently make a lick of sense.

The current version of the article is extremely Haskell-centric. There are plenty of tutorials on Haskell monads on the web. There's no need for the Wikipedia article to be one as well.

Just to be clear, I don't have a problem with the use of Haskell as the language to illustrate monad concepts. But the current presentation is very much "here's how to use monads in Haskell". In particular, phrases like "To define a monad in Haskell...", and the discussion of Haskell's do-notation seem more appropriate for a Haskell article than a general article on monads in FP. --Allan McInnes (talk) 20:22, 22 June 2006 (UTC)[reply]

Unfortunately, I agree that if it's too abstract people won't actually be able to learn from it. For people coming from a CS rather than a maths background, Monads are rather tricky.—The preceding unsigned comment was added by 203.59.86.86 (talk • contribs) .

I agree too. I'm trying to completely grasp continuations as monads so I can add them to this. In the papers I've looked at thus far, most of them use Haskell. It'd probably be best to keep the explanation here as is, but move some of the Haskell-centric stuff (like the do-notation stuff) to another page --NotQuiteEXPComplete 12:25, 3 August 2006 (UTC)[reply]

I wish there was a way to include comments right in the article on Wikipedia, but we don't have that, so I'll try to explain where I want changes. My comments refere to the version as of http://en.wikipedia.org/w/index.php?title=Monads_in_functional_programming&oldid=84889989

Section Motivation: the first code example: I think this is Haskell code, but it's not apparent that it really is. Please be explicit about that. "par" is a bad function name; it isn't obvious that it has anything to do with parallel connection of resistors. Better to call it foo, or something. The syntax of the two lines of code is not obvious. The meanings of :: and -> are non-obvious.

Second code example: Is ... a part of the code? The meaning of :: and -> are again non-obvious. In an electrical engineering program, I'd like to use // as an operator means 1(1/x + 1/y), i.e., parallel connection, since the operator consists of two parallel lines. Therefore it's a bad choice for the meaning here; a new form of division.

The last sentence of the code example suggest that the example is wrong. Is it?

Section Definition: Shouldn't this be a definition of monads in functional programming, rather than monads in Haskell?

What does | (vertical bar) mean?

Are the words "data", "Just", "Nothing", parts of the Haskell language?

Is the character ≡ a part of the Haskell language?

Section Failure: Is the word "mzero" a part of the Haskell language, or of functional programming vocabulary?

The Maybe monad example: What does "'", "in" and "let" mean?

The rest of the article is left for a later time.

You can include comments just fine. "<!-- Comment on FOO -->" does it just fine inline. --Gwern (contribs) 21:00 27 November 2006 (GMT)

Shouldn't Monad (functional programming) be the main name of this article? The discussion above doesn't really explain the reason for the name. --Bkkbrad 01:44, 26 December 2006 (UTC)[reply]

Yeah, it probably should be. — Matt Crypto 17:34, 26 October 2007 (UTC)[reply]

Oh, but see Talk:Monads_in_functional_programming#Merging_articles_and_the_name_of_the_article. — Matt Crypto 13:32, 29 November 2007 (UTC)[reply]

My haskell is a bit rusty, but it seems to me that
(return x) >>= f ≡ f x
should be
(return x) >>= f ≡ return (f x)
—The preceding unsigned comment was added by 129.29.227.4 (talk) 13:16, 27 March 2007 (UTC).[reply]

I don't think so...if x has type a, and f has type a -> m b, then return x >>= f will have type m b, the same as f x. return (f x), on the other hand, will have type m (m b), since return has type a -> m a. Nick8325 14:52, 27 March 2007 (UTC)[reply]

Nick8325 is definitely correct on this count. 67.173.144.59 (talk) 17:42, 15 February 2009 (UTC)[reply]

So I don't understand what Monads are, and after reading the article twice, I still don't know. The opening of the article explains what they are used for, but not what they are. The 'maybe' example is semi-understandable, but nothing explicitly states what problem Monads are solving. The definition given is nice and formal but totally inaccessible to anyone that doesn't already know what's being talked about. Is there some analogy that might be used to explain it? I haven't written a lot of code in functional languages (although I have written a little), never used Haskell, but I do have a Ph.D. in software engineering. 68.4.228.48 17:38, 10 June 2007 (UTC)[reply]

Wikipedia is not a tutorial. The article links to the Haskell Wikibook's Understanding monads section; failing that, the Haskell wiki has a diverse list of other monad tutorials. --Piet Delport 04:55, 11 June 2007 (UTC)[reply]

Ah, so it's not the purpose of Wikipedia (supposedly an encyclopedia) to explain something so that it's minimally understood. Gotcha. Gazpacho 16:54, 9 August 2007 (UTC)[reply]

No need to be snarky. The purpose of Wikipedia is to explain, but not to teach. Less textbook, more summary and reference. —Piet Delport 2007-08-09 19:49

Nonsense. Definition that define terms recursively fail the philosophy 101 test. "Monads are objects that have a lot of monadic flavor to them." is not a valid definition of what a monad is. I wish I could get close to such faux intellectuals such as yourself and punch you in the face, because you don't understand logic and reason. There is no real difference between teaching and explaining. If an explanation fails to elucidate the matter, it is not an explanation at all. What is teaching besides elucidation? The only thing that teaching can add on top of elucidation is memorization and rote practice, but elucidation is an essential element in teaching. So to say that because Wikipedia does not aim to teach it no longer needs to be lucid is pure nonsense. To philosophy 101 with all you idiots. You don't deserve respect or politeness. You offend my faculties of mind, foul pseudo-fiends that you are. Ptoooey. "Will someone please respect me.... whaaaaaa!!!! I am so smart, I can write things that no one can understand!!! waaaaaa!!!" Enough of this. Is it any wonder that functional programming fails to take root? It's all thanks to arrogant and ignorant bastards that write articles like these. -- Someone who took Philo 101. (I'm not Matt, the guy below)

The problem is that Wikipedia didn't explain it that well either.--71.232.157.145 02:47, 11 October 2007 (UTC)[reply]

To be fair, monads can be a tricky thing for most people to get their heads round. As a result, it's not straightforward to explain it in a very accessible way without it becoming a lengthy tutorial. I reckon we could still do better though. — Matt Crypto 17:32, 26 October 2007 (UTC)[reply]

exactly. This article doesn't seem to explain what monads are, but how they work.--84.63.57.88 (talk) 09:32, 29 November 2007 (UTC)[reply]

One problem I had reading this was that the article seemed to assume familiarity with Haskell syntax. In particular, unless you know something about the precedence and associativity of the Haskell operators used in the code, then some of the discussion can be unnecessarily confusing. For example, is -> left-associative? commutative? what about >>=? The use of parentheses in the binding axiom seems to suggest that these issues are important, but the reader has no way of determining the answer. I am not entirely sure how to fix this problem, since certainly this is the most comfortable notation for most of the authors of this page. On the other hand, it runs the risk of being a page that can only be read by people who don't need it. Perhaps I'm over-thinking this and just adding a bunch of extra parentheses would solve the problem (even if the added parentheses would be non-idiomatic in normal use of Haskell). --Rpgoldman (talk) 22:17, 15 April 2009 (UTC)[reply]

The reference "The three fundamental laws of Monad" does not exists anymore. Is the content at a new spot on the net? 87.163.118.84 09:15, 27 July 2007 (UTC)[reply]

"All About Monads" now resides at [2]. -- 195.4.115.231 09:18, 3 August 2007 (UTC)[reply]

First off, whoever wrote the "Maybe" example, thanks; it's been really helpful in getting my head around this. :) That said, there's something in there that doesn't seem right, and I think it may be an error. Specifically, it looks to me like

(Just x) >>= f = Just (f x)

should be

(Just x) >>= f = f x

f should be of type a -> Maybe b; Just (f x) would be of type Maybe Maybe b, which wouldn't be right. (The standard prelude has (Just x) >>= k defined as k x.)

This also makes the "4 stages of binding" bit that precedes it seems a little misleading. I don't think the "piercing" of the result of the function being bound happens in Haskell unless you explicitly ask for it to (by, say, pattern-matching the result of the function being bound). In the case of Maybe, it's simply returning the function result straightaway.

I'd love to get some other thoughts on this, since I'm just getting started with Haskell!

Ngroot 19:44, 8 September 2007 (UTC)[reply]

Ironically, I came here to make an edit because the "Just" is missing. Recall that the result value should be of type "M u". I've added the clarification "(and wrapping the result in the monad type)"; i.e. what is done is this: "(Maybe x)" =extract_value=> "x" =apply_function=> "(f x)" =wrap_into_monad_type=> "Just (f x)". It has to be done this way, because at any moment, the computation could fail, resulting in "Nothing". All successful results are wrapped in "Just". ToolmakerSteve (talk) 21:00, 19 April 2008 (UTC)[reply]

I've now also changed 'A Maybe type is just the underlying type' to read 'A Maybe type is the underlying type wrapped with "Just"'. I am hoping this helps clarify that inside the Maybe monad, all values that aren't Nothing are wrapped in "Just". At each computation step, there is a simple test for "Just" or "Nothing". ToolmakerSteve (talk) 21:36, 19 April 2008 (UTC)[reply]

I'm experimenting with the equivalent of monads in F#; now I understand what Ngroot was saying. This needs to be rewritten, as it is unclear whether the "f" here is referring to a function returning a monad type, (which is why Ngroot saw the result as becoming "Just (Just ...)" as written), or the underlying function operating on the underlying value. ToolmakerSteve I am attempting to rewrite by introducing "f'", which is the monadic function that applies the underlying "f" and wraps it with "Just" on success, or returns "Nothing" on failure. (talk) 23:15, 19 April 2008 (UTC)[reply]

I found the initial description of the binding operation, with its four stages very intuitively appealing, but as I carried on in the article, I became confused. The problem for me is that in the third clause of the definition, binding is defined as taking a monad of underlying type t and a function t → (M u) and returning a value of type (M u). This seems clear enough. However, in the axioms section, all of a sudden we are told about binding two functions in succession, without any explanation of what this means. It may be that the use of Haskell notation here is just confusing me --- I would be happier if the axioms were presented in familiar mathematical notation instead of unfamiliar Haskell notation (see my remarks earlier on this page). I may further be confused by the (to me) very odd use of the term "binding," which I am familiar with from other functional programming contexts as being something that happens to variables... Quite possibly a concrete example would make this all crystal clear. --Rpgoldman (talk) 22:29, 15 April 2009 (UTC)[reply]

I've changed the Importance level to Mid. This subject is central to current practice in functional languages, at the same level than Design Patterns in OOP. But feel free to discuss. Diego (talk) 07:35, 26 June 2008 (UTC)[reply]

I can't understand what monads are from this article.

The first paragraph describes what monads are used for instead of describing what they are, contrary to Wikipedia guidelines. The rest of the articles then constantly mixes definitions referencing unexplained terms, like 'monadic type' with examples written exclusively in Haskell. —Preceding unsigned comment added by 87.18.173.1 (talk) 10:03, 6 July 2008 (UTC)[reply]

Absolutely agreed. "Here's a bit of code in a pseudo-language lacking any referents you'll recognise. To add confusion, we use a custom operator, //, which we have to define in detail. The Maybe monad doesn't appear in this code and is only mentioned briefly at the end of the description. From this you can deduce what a monad is, despite the fact that we've not explained what the Maybe monad is, what makes it a monad, why it's appropriate, and why we chose not to define it here." Better still, go to the Maybe monad section for enlightenment, and it says "The Maybe monad has already been defined above". So by implication I have to read 2/3 of the article to understand the lead-in paragraphs. Must Try Harder. --62.58.152.52 (talk) 12:21, 27 October 2009 (UTC)[reply]

I just removed the following from the article: A "monad" should not be defined in terms of itself. That's bullshit (philosophy 101?). Please define what "monad" is without using the term "monad" to define it. If you cannot, I venture to say you don't understand it yourself and shouldn't be writing Wikipedia entries. I pray to God whoever wrote this were not a University professor, for it would indicate a sorry state of our education. (byUser:64.236.243.16)

It *is* definitely inappropriate to have a "definition" section that uses "monadic" without first defining what it means, even if the definition occurs later. shreevatsa (talk) 22:31, 15 July 2008 (UTC)[reply]

I have done some working on the leading paragraph, I hope this provides a more clear definition and some insights in what monads are used for. Although the complaint was rude, their point was valid. Diego (talk) 08:13, 16 July 2008 (UTC)[reply]

Great work, the lead looks much more clear and encyclopaedic now. The "definition" section could use some improvement though. Even simply renaming a part of it to something other than "definition" would be an improvement :) shreevatsa (talk) 12:07, 16 July 2008 (UTC)[reply]

I removed the following from the bind disambiguation page, so it can be merged with (say) this article. Please feel free to merge.

• When using monads in functional programming, bind is an operation of monads. A simple example (enabled by the fact that sets can be regarded as monads as well): Let A be a set, ${\displaystyle f:A\to 2^{B}}$, ${\displaystyle A_{0}\subseteq A}$, then )\mid a\in A_{0}\,\right\}}"> A 0 > > = f = ⋃ { f ( a ) ∣ a ∈ A 0 } {\displaystyle A_{0}>\!\!\!>\!\!\!=f=\bigcup \left\{\,f(a)\mid a\in A_{0}\,\right\}} a)\mid a\in A_{0}\,\right\}}"/>, thus, f is applied pointwise and the union of the intermediate results is returned.

Widefox (talk) 10:38, 7 November 2008 (UTC)[reply]

Moving this comment from the article's body so that it can be discussed..Diego (talk) 18:13, 6 December 2008 (UTC)[reply]

"to define arbitrary control flows (like handling concurrency, continuations, or exceptions)." Are they really that general? What, then, are monoids and arrows for? My understanding was that they described more general computations but had fewer laws one could reason with.

Monads support some arbitrary control flows, not all them. Arrows allow some more flows (for example, non-deterministic concurrency) which is not supported by monads Diego (talk) 13:46, 19 October 2009 (UTC)[reply]