Talk:Monads in functional programming

From Wikipedia, the free encyclopedia

This article is part of a WikiProject to improve Wikipedia's articles related to Computer science. For guidelines see WikiProject Computer science and Wikipedia:Contributing FAQ.

Contents 1 Merging articles and the name of the article 2 par function 3 Rewrite 4 Haskell 5 Just markup issue 6 Monad and sequencing 7 Rewrite on 2006-05-08 8 Editorial wish-list

[edit] Merging articles and the name of the article

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)

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)

[edit] par function

Why is the function called par? --MarSch 11:06, 25 October 2005 (UTC)

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

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)

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)

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)

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)

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)

[edit] Rewrite

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)

[edit] Haskell

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)

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)

[edit] Just markup issue

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)

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)

[edit] Monad and sequencing

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)

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)

[edit] Rewrite on 2006-05-08

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)

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)

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)

[edit] Editorial wish-list

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)