tag:blogger.com,1999:blog-11295132.post2439830144908752127..comments2024-02-24T01:46:31.188-08:00Comments on A Neighborhood of Infinity: The IO Monad for People who Simply Don't Caresigfpehttp://www.blogger.com/profile/08096190433222340957noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-11295132.post-14186278057994010032008-02-15T14:14:00.000-08:002008-02-15T14:14:00.000-08:00yeah, if you are coming from the pool of most prog...yeah, if you are coming from the pool of most programmers then the names chosen for the operations required to be a monad do, verily, confuse at first :-)Raoul Dukehttps://www.blogger.com/profile/07354740962526930549noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-10518724575063095782008-01-03T01:29:00.000-08:002008-01-03T01:29:00.000-08:00I have never understood why the word "return" was ...I have never understood why the word "return" was chosen - it just lends itself to too much confusion and ambiguity for programmers arriving from imperative languages.<BR/><BR/>I wonder why something like "wrap" wasn't acceptable?Unknownhttps://www.blogger.com/profile/02948105455433369982noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-30704987205900614262007-12-23T16:48:00.000-08:002007-12-23T16:48:00.000-08:00Can't thank you enough for the article. Finally, a...Can't thank you enough for the article. Finally, a practical example of Monad that covers the necessary details.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11295132.post-16896439120508129892007-12-03T16:27:00.000-08:002007-12-03T16:27:00.000-08:00Hey Tim,You're absolutely right about "return", it...Hey Tim,<BR/><BR/>You're absolutely right about "return", it could be misleading. For example, imperative programmers might be surprised about the result of:<BR/><BR/>main = do<BR/> return 1<BR/> print "Hello"<BR/><BR/>I guess one (bizarre) way to look at it is that "return" is actually returning its value to the next statement, but that would need some qualification to make it precise.<BR/><BR/>But the easiest fix for now is to change rule 2 to "To return a value from the end of a do-block, use return."sigfpehttps://www.blogger.com/profile/08096190433222340957noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-46879828964390173882007-12-03T16:11:00.000-08:002007-12-03T16:11:00.000-08:00Loved it! I'd read it again and again! My only q...Loved it! I'd read it again and again! <BR/>My only quibble is in the description of "return" as "returning" a result. The word "return" has a very specific and very different meaning to imperative programmers and is an easy place to get in trouble. I think its always worth going out of the way to say that "return" does not affect control flow.newshamhttps://www.blogger.com/profile/10474447258819808743noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-80391173808124392222007-12-01T05:13:00.000-08:002007-12-01T05:13:00.000-08:00let x = 1+2+3+4+5+6 print "The answer is" pr...let x = 1+2+3+4+5<EM><B>+6</B></EM><BR/> print "The answer is"<BR/> print (2*x)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11295132.post-17915602881018431542007-11-29T23:11:00.000-08:002007-11-29T23:11:00.000-08:00If you had to build all your lists using do notati...If you had to build all your lists using do notation, you probably would call it "the List Monad".GMhttps://www.blogger.com/profile/07637024036051297719noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-40872496449006397572007-11-29T16:52:00.000-08:002007-11-29T16:52:00.000-08:00mark,It took me a while to remember what I meant b...mark,<BR/><BR/>It took me a while to remember what I meant by scray. That's pretty scray in itself. :-)sigfpehttps://www.blogger.com/profile/08096190433222340957noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-28237757905229238542007-11-29T16:49:00.000-08:002007-11-29T16:49:00.000-08:00scray?scray?Markhttps://www.blogger.com/profile/08351763039619833431noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-38077445060091379232007-11-29T10:56:00.000-08:002007-11-29T10:56:00.000-08:00So, one thing left out with this analogy is that c...So, one thing left out with this analogy is that commands can either be used as expressions or, for lack of a better word, "executed". In do blocks, they're executed (or rather, the do block defines a new command that, when executed, executes the commands, etc.). But they can also be stuffed in lists, etc.<BR/><BR/>In some ways, thinking of it as an "inside out" imperative language (do notation) with a super-gonzo extended macro language that puts some stuff off until runtime (normal expressions) isn't too far off.Aaron Denneyhttps://www.blogger.com/profile/15613957348593645695noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-63591070551084655252007-11-29T09:07:00.000-08:002007-11-29T09:07:00.000-08:00mikael,Actually, I dropped the inner 'do's. But yo...mikael,<BR/><BR/>Actually, I dropped the inner 'do's. But you've probably spotted that I could have dropped the outer 'do' to.sigfpehttps://www.blogger.com/profile/08096190433222340957noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-63533823416704250402007-11-29T07:32:00.000-08:002007-11-29T07:32:00.000-08:00Good post and covers the basics well. But then t...Good post and covers the basics well. <BR/><BR/>But then the next question that always comes up is how to do IO down in an function (in an expression) down a ways in the code. This often involves rewriting those "expressions" into "commands". (Certainly unsafeperformio is always lurking around.) Explaining why this needs to happen (and then explaining how) can be quite difficult - especially to people brought up on C, Java and the like where this is easy.jefuhttps://www.blogger.com/profile/02233639532468393698noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-37282370083436071962007-11-29T02:31:00.000-08:002007-11-29T02:31:00.000-08:00Hey, I like your explanation of the use of the IO ...Hey, I like your explanation of the use of the IO monad very much. I think this is the kind of text we need much more in computer science: "lying a bit" to convey notions, ideas, conceptions, patterns of use in a simple, easy to grasp manner. It's a powerful technique to prepare the path to the full truth.<BR/><BR/>Dominikusdhhttps://www.blogger.com/profile/14802254686725596321noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-91467725307058702002007-11-29T01:49:00.000-08:002007-11-29T01:49:00.000-08:00You say that we can drop do in some contexts, and ...You say that we can drop <I>do</I> in some contexts, and give an example, but the example doesn't drop the <I>do</I>.michiexilehttps://www.blogger.com/profile/00008302080954798496noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-53234947706011661662007-11-29T01:47:00.000-08:002007-11-29T01:47:00.000-08:00I agree with sigfpe.Your article easy understand f...I agree with sigfpe.<BR/><BR/>Your article easy understand for people who might otherwise be put of Haskell.Anonymoushttps://www.blogger.com/profile/06806442027905887893noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-78359236230824208972007-11-28T21:44:00.000-08:002007-11-28T21:44:00.000-08:00I can't say I disagree with you that much.I'm just...I can't say I disagree with you that much.<BR/><BR/>I'm just trying to provide some rules of thumb in an attempt to attract people who might otherwise be put of Haskell. In a sense I've described a subset of Haskell where commands and expressions really are syntactically distinct - I think I've sketched out a portion of a grammar where commands and expressions can't be freely mixed. Later on, I'd hope that programmers would realise that commands really are just expressions.<BR/><BR/>> Monadness is no more essential to the IO type (constructor) than to list.<BR/><BR/>I entirely agree. My intention is to show that despite the fact that IO is called "the IO monad", it really isn't scray at all. That's why I try not to talk about monads later.sigfpehttps://www.blogger.com/profile/08096190433222340957noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-74051641726455759652007-11-28T21:33:00.000-08:002007-11-28T21:33:00.000-08:00Hm. I think the "command/expression distinction" ...Hm. I think the "command/expression distinction" is a confusion of semantics & syntax. I'd say that Haskell "expressions" are used consistently to denote a wide variety of (immutable) values, from booleans & numbers to streams & trees to imagery & animation, to "commands" (aka "computations", "stateful computations", "actions", "commands", IO values) & beyond. All are denoted (expressed) via expressions, and all are immutable values. The only essential difference between IO and, say, list is that the semantic interpretation we give IO is much more complicated (intractably so) than the one we give lists.<BR/><BR/>I also have a quibble with the common practice of referring to IO as "the IO monad". Monadness is no more essential to the IO type (constructor) than to list. Bringing in monads is just a convenient structuring technique. The idea of capturing imperative computations in a type of (immutable) values is lovely. And so is the general pattern we call "monad". I'm worried that people won't understand that these lovely ideas can be used separately, and that (like infinite lists), they happen to be usable together.Conalhttps://www.blogger.com/profile/05756984502464196668noreply@blogger.com