tag:blogger.com,1999:blog-11295132.post5737726437521112277..comments2009-01-19T07:01:31.725-08:00sigfpehttp://www.blogger.com/profile/08096190433222340957noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-11295132.post-184890297135528562007-06-27T15:02:00.000-07:002007-06-27T15:02:00.000-07:00Steven,<BR/><BR/>In pure functional programming languages you aren't allowed to cause side effects. The only way a function can 'interact' with the outside world is to return something. So if you have a function that needs to return a number, but has a certain side effect, the only way to do this is to return the number and return some data 'containing' the side effect. But that's a pain in the ass - you have to write all of your code to return multiple values, and you have to write plumbing code to pass these side-effect containing values around. What monads can do is give a uniform API to side-effect containing data so you can just concentrate on the number that you want to return, and have the side-effect carried along automatically in the background. What's neat about monads is the same API can be used for many different problems, not just handling side-effects.<BR/><BR/>So half the time when dealing with monads we're solving a problem that we've caused in the first place by using a pure functional language. (But sometimes it's worth using a pure functional language because of other benefits.) The other half of the time we're using monads because they provide facilities that are very hard to implement otherwise - such as logic programming or continuation passing style. I've not given C++ examples of the latter because it would be way too hard. So I've only given examples of things that you can easily implement already in C++.<BR/><BR/>If you ever get a chance, check out the list monad in Haskell. It's beautifully simple, and yet it takes a considerable amount of work to implement the same thing in C++.sigfpehttp://www.blogger.com/profile/08096190433222340957noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-154045012746790802007-06-27T14:24:00.000-07:002007-06-27T14:24:00.000-07:00Perhaps I misunderstood, but it looks like the wrapping and unwrapping is being done to hide data in these examples.<BR/><BR/>I guess I need to see a more complex example where the pattern makes something easier/clearer to understand why I'd want to use it.<BR/><BR/>I'm not trying to be difficult, I'm just slow (at least when it comes to monads). :)Steven Brandthttp://www.blogger.com/profile/02657324020868587426noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-18986694045260265942007-06-27T07:57:00.000-07:002007-06-27T07:57:00.000-07:00Steven,<BR/><BR/>Not sure what you're trying to achieve using a private member.<BR/><BR/>My goal here isn't to do anything useful but to simply translate one of the simplest monads into C++ to make the way it works more apparent to people with a C++ background. It's not something that anyone would really write in C++, it's just a baby example in the hope that it illustrates the pattern. A more sophisticated monad like the list monad allows you to do things like logic programming in Haskell, something that is much more difficult to implement in C++ and really leverages the usefulness of monads. But it helps to understand these simple examples first.sigfpehttp://www.blogger.com/profile/08096190433222340957noreply@blogger.comtag:blogger.com,1999:blog-11295132.post-28483366895713125502007-06-27T07:28:00.000-07:002007-06-27T07:28:00.000-07:00If you were doing this in C++, you could just accomplish this by labeling a variable as private, right? Then you wouldn't need to wrap and unwrap it all the time.<BR/><BR/>I keep looking at examples like this of monads, and I can't figure out what the excitement is.Steven Brandthttp://www.blogger.com/profile/02657324020868587426noreply@blogger.com