tag:blogger.com,1999:blog-33103854.post6854872141290785431..comments2023-05-22T14:15:21.482+02:00Comments on Karsten Wagner's Blog: Real functional programming or "Why the IO-monad is evil"Karsten Wagnerhttp://www.blogger.com/profile/09652404623625038743noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-33103854.post-81682118951956348422010-08-18T13:22:29.711+02:002010-08-18T13:22:29.711+02:00I read your article, and it seems that you did not...I read your article, and it seems that you did not understand monads. Haskell is as pure as Clean (and does not rely on a strange addition to it's type system).<br /><br />In general, monads do nothing else than making the world parameter implicit by abstracting it with a combinator (">>="). At the same time, this guarantees single threadedness, for which Clean needs it's Maximilian Clausnoreply@blogger.comtag:blogger.com,1999:blog-33103854.post-89890593090196826592007-02-01T15:56:00.000+01:002007-02-01T15:56:00.000+01:00George, syntax sugar is half of it. The other half...George, syntax sugar is half of it. The other half is making sure you don't try to, for example, copy the world, and in one thread of the world ask X, read Y, and the other ask Y, read Z. Since we can't currently fork() the world, the IO monad takes steps to prevent this kind of copying from happening.bd_https://www.blogger.com/profile/01560746058527855728noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-15668373085509667532007-02-01T13:22:00.000+01:002007-02-01T13:22:00.000+01:00From what I understand, the Monad is just some syn...From what I understand, the Monad is just some syntax sugar around the 'world' concept. They are the same thing.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-33103854.post-515591853196236822007-02-01T01:30:00.000+01:002007-02-01T01:30:00.000+01:00> Because any turing-complete language can be tran...> Because any turing-complete language can be translated into any other turing-complete language, all turing-complete languages are the same?<br /><br />I tried to point out the exact opposite: Because we can do this translation with every language, we have to acknowledge that the IO-monad creates a sub-language which is not a functional one. Even if it is maybe translated into pure functional Karsten Wagnerhttps://www.blogger.com/profile/09652404623625038743noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-76101796007065889822007-01-31T22:13:00.000+01:002007-01-31T22:13:00.000+01:00You're quite right that passing a world around lik...You're quite right that passing a world around like this lets you write a purely functional program that talks to the outside world. It seems you have reinvented the idea yourself, which is pretty impressive, but you haven't quite gotten around to realizing the IO monad is referentially transparent for the same reason. Basically, IO a is just an abstract synonym for functions taking a world and Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-33103854.post-12673897226053966252007-01-31T20:50:00.000+01:002007-01-31T20:50:00.000+01:00Because any turing-complete language can be transl...Because any turing-complete language can be translated into any other turing-complete language, all turing-complete languages are the same?<br /><br />The value of getStr :: IO String is the same on every invocation (actually, it doesn't have invocations, since it's a constant). It's always an IO action that will pass the string given by the user at that point in the program to the next functionAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-33103854.post-34351576312321990882007-01-31T18:30:00.000+01:002007-01-31T18:30:00.000+01:00@Adam Ierymenko:
> What about concurrency? What i...@Adam Ierymenko:<br /><br />> What about concurrency? What if an element of world changes *after* it is lazily evaluated and then needs to be lazily evaluated again? Doesn't this still break the functional model? <br /><br />No, because the 'world' can't change 'backward in time'. If you have a dynamic 'world', then you wouldn't use a static snapshot but a list of events instead. Or you transformKarsten Wagnerhttps://www.blogger.com/profile/09652404623625038743noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-61819102217779513692007-01-31T16:08:00.000+01:002007-01-31T16:08:00.000+01:00It may interest you to know that your World-transf...It may interest you to know that your World-transforming recommendation is <i>pretty much</i> GHC's implementation of IO. No, not just "pretty much", <i>you have implemented it</i>. Check out the Haskell wiki article <a href="http://haskell.org/haskellwiki/IO_inside">IO inside</a>.<br /><br />A type 'IO a' <i>is</i> a function that takes the World, transforms it, and results in the both an 'a' Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-33103854.post-75027429286221565182007-01-31T14:02:00.000+01:002007-01-31T14:02:00.000+01:00pete - the idea is that the "world" is a script of...pete - the idea is that the "world" is a script of everything that will happen to the program. So by definition, every time you run the program with the script, it will produce the exact same output. <br /><br />An IO monad is different - it's just a door through which the user shoves information. There's no "guarantee" that the result will be the same.<br /><br />Having said that, Karsten, Geek Vaderhttps://www.blogger.com/profile/05729378883810714043noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-77710813238328626232007-01-31T13:35:00.000+01:002007-01-31T13:35:00.000+01:00What about concurrency? What if an element of wor...What about concurrency? What if an element of world changes *after* it is lazily evaluated and then needs to be lazily evaluated again? Doesn't this still break the functional model?<br /><br />Absolutely pure FP does indeed seem to have a problem. I suspect this is why FP is not in general use and why functional langauges tend to take on non-functional hacks for things like IO.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-33103854.post-65594401609907304952007-01-31T13:30:00.000+01:002007-01-31T13:30:00.000+01:00The IO monad is not the 'world', because you can't...The IO monad is not the 'world', because you can't put anything into functions using it. A function like getStr don't need any input, it only returns a value.What 'getStr' really is, is a statement in an imperative sub-language created by the IO monad. The 'getStr' function don't returns the string-value, it returns a 'statement' which is executed later - and <i>this</i> statement then returns Karsten Wagnerhttps://www.blogger.com/profile/09652404623625038743noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-41900007819453426062007-01-31T10:45:00.000+01:002007-01-31T10:45:00.000+01:00I'm relatively new to FP so I admit that what you'...I'm relatively new to FP so I admit that what you've written leaves me somewhat baffled.<br /><br />It seems to me that the IO Monad is basically your "world" set up differently. Please explain (short words, for us simpletons) how this is not so.<br /><br />As for your final example and suggestion that the execution order is not clearly defined...I don't think that is true. What you are really Brushboxhttps://www.blogger.com/profile/01830988952418641005noreply@blogger.com