Monads

How are monads different than side effects?

Are we talking about statically-typed Nomads or dynamically allocated Monads?

Monads are a general concept. They are nothing particular to side effects.

The IO monad, in particular, is different from allowing side effects anywhere because the side-effect-causing actions are first class and can be manipulated and combined (in a pure manner). Having no side effects in the core language allows for a lot of nice things. For one, it makes parallelism easy. It also makes the using lazy evaluation more predictable.

Haskell Monads are actually a triplet of an abstract data type, and the functions bind and return. Each monad has its own specific bind function and its own specific return function. You can use monads as a way of abstracting "common computations". Monads can be also used to implement a sort of "container" for data. As for side effects in monads, you're probably thinking about the IO monad which can be thought of as a container that manages side effects to the real world.

Guys, shut up. Just, shut up.

Monads are not particular to modeling side effects. They're basically for any situation where you need to shuffle data in and out of containers while not having to be explicit about how the wrapping and unwrapping is actually done.

This is a "stupid" explanation, but it's still better than talking about triples and categories.

Anyway, the only reason monads are used for side effects in Haskell is that you have a data type that represents "the part of the world that allows side effects." This is, of course, everything outside your program. Other data types usable as monads include lists, Maybe, and yes, State.

As for side effects only being allowed in IO functions: Haskell is not the first to do this. For example, Ada (it was popular with the military for years... you might have heard of it) has always separated "functions" from "procedures" and prohibited the former from having any side effects outside of the local variables of the function. This is basically mandatory in any safety-conscious language, apart from the ones that do shit like prohibiting dynamic allocation.

Monads are containers for pointers that may overflow your stack.

>>5
As for side effects only being allowed in IO functions: Haskell is not the first to do this. For example, Ada (it was popular with the military for years... you might have heard of it) has always separated "functions" from "procedures" and prohibited the former from having any side effects outside of the local variables of the function. This is basically mandatory in any safety-conscious language, apart from the ones that do shit like prohibiting dynamic allocation.
Does Guido have an Ada background?

Ada is fucking awesome. One of the best languages I've ever used.

It's no surprise it didn't win much popularity.

Ada is like wearing a suit of armor. Yes, it will keep you safe, but don't even think about going swimming.

Haskell is also like wearing a suit of armor.... and being Tony Stark.

>>9
It's not that restrictive once you get used to it.

Important Door
Monad bumble

Monads are just a way to organize computation and avoid
non-deterministic results for non-commutative operations like IO.

For example, when you say f(x) + g(y), their order of
execution is not and should not be defined. But what if they have side
effects, e. g. puts("lol") + puts("wut")? We can say that
every function with side-effects takes world as an implicit argument and
returns it, thus we can have puts("wut", puts("lol", world)).
The external puts() depends on its second argument, so the internal puts()
get executed first and there's no way around that. It can be generalized
for arbitrary computations, not only IO.

Please correct me if I'm wrong.

>>13
Wouldn't taking world as an implicit argument require a lot of resources(memory), and it may not even be possible for things which can't be read by the app(hardware state, internal OS structures, and so on). Does it just assume taking world as an argument and isolate whatever sideeffects are generated from the rest of the application?

>>13
>>13
I lol'd

>>13
What makes you think the arguments are copied?

>>14
Unchecked Recursion is no laughing matter, I had a friend that blew his stack that way.

>>16
Actually, your friend blew my stack, if you know what I mean.

>>17
Reported.

>>18
No one cares.

I've never done any serious Haskell programming, but I learned what monads would be useful for from Erlang:

{Token1, Rest1} = parseShit(Input),
{Token2, Rest2} = parseShit(Rest1),
{Token3, Rest3} = parseShit(Rest2),
% do shit with Tokens, return {Result, Rest3}

I presume monads are for converting that into

Token1 = parseShit(Monad),
Token2 = parseShit(Monad),
Token3 = parseShit(Monad),
% do shit with Tokens, return Result

But every buttfucking, shiteating, micropenised Haskellite always waxes philosophically and orgasmically about endless academic BULLSHIT about monads instead of actually telling what the fuck they're for!  Just like this >>4 dickhead.

Fuck Haskellers.  Cool language, though.

>>19
I care

>>21
I like to ram my dick in greasy diesel engines.

>>20
But every buttfucking, shiteating, micropenised Haskellite always waxes philosophically and orgasmically about endless academic BULLSHIT about monads instead of actually telling what the fuck they're for!  Just like this >>4 dickhead.

This. For the love of The Sussman, this.

I'm >>5, by the way.

>>20
I am >>4. Monads are more powerful and yet, more elegant than most people realise. Our problem is explaining monads in a way that the non-satori would understand. To understand our problem, you need to have a fair understanding of what are monads and what they are used for. If you don't have an understanding like we do, I just want to say this: monads are an elegant way of expressing a huge range of computations. So yes, we do have a problem with explaining monads. http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html If you can truly follow this web log, then you're definitely on the road to monadic satori.

They're basically for any situation where you need to shuffle data in and out of containers while not having to be explicit about how the wrapping and unwrapping is actually done.

This is a excellent and simplistic explanation of what a monad does.

http://stefan-klinger.de/files/monadGuide.pdf

>>22
That's nice. Perhaps you should share this wonderful information to the denizens who reside in http://img.4chan.org/b/imgboard.html

what the hell does
do anyway?

Write me a monad tutorial, /prog/

>>28
see >>25.

Perhaps you ought to return to your previous state of communicating on the Internet image board, originally based on 2channel, http://img.4chan.org/b/imgboard.html

>>28
Here's your monad tutorial:

Monads are only useful if there are several or more of them.

>>24
So stop fucking talking about them like they're inherently some kind of weird, abstract branch of mathematics that's powered by the Force and that nobody's ever heard of. I swear, if everyone would just stop doing that, the number of Haskell programmers would double overnight.

>>32
                    ,______ ___ ___ ____.,
                  /*      '   '   '        \_
                 |                           \
                -                             ~
               |                               \
               -                                |
              /                                 \
             -   ________________________       \
      .     _  _/                         \_    \    __.,._
    .   \..,  /                              \,. *__/      \
      '*                                        /          *
       /                                        |         /
       \_     ,._.#####.__.    .___#####._,.   /-      -.-
         *,==|  <._# )>    vvvv   <. # )>   |==#"      \
       /     |            |    |            |  \       *
        ^_   |      .,-* /      \           |  /      /
         /_ /\__________/        \_________/   -     |
           /           (__    __ )               |  / \__,
           |               **      \           /   " /.
           "        /               \          \_- /   /
           \       /                            / v   |
            -                                   |  /
             \      ,-''"''--"''"'-..          / \
              \      \.,.-,.,.--,.../           |
               \_                             |
                 \_                   _____  /.
              .-/  <>>>____,.,..,____/ ___  / \
           ,./  \                             .
         ,.*/    \                            |\
        *  *      \                            /\
  ,.___/  |        \                          /  |

          \MAY THE FORCE BE WITH YOU YOUNG WIZARD
           |                              -- G. J. Sussman

the number of Haskell programmers would double overnight.
wishful thinking

Recursion is all about wistful thinking

--The Sussman

>>28
Okay.

I'm gonna make this quick, and assume you don't know a whole lot of Haskell. I'm also going to use weak analogies, which automatically makes them bad analogies, which means that before you even have a chance to read this, a thousand thousand slimy things will crawl all over the thread and scream at the top of their lungs about how harmful my post is to the human mind.

Anyway.

Monad is a typeclass. (That's kind of like an interface, in Java/C# parlance. You don't need OOP to have inheritance or polymorphism.) It has two methods you need to know about:

1) return, which is totally unrelated to the C-family concept of return. It's a function that takes an arbitrary value and puts it into a monadic container. (Remember, it's just a function.)
2) The operator >>=, also known as bind, is a little more complicated. If you have a function foo that returns a monadic value (that is, a value that's been wrapped up by return) and a function bar that needs a single, unwrapped argument, you can write foo >>= bar to unwrap the return value of foo and pass it to bar.

If you've ever done leet hax0r shit on the command line, you'll know that in Unix/Linux you can pipe the output of one command to the input of the next. If you need to use a command that only takes standard input and won't read from a file, you can use cat to read the file from disk and then pipe cat's output into your next command.

Unix: cat sting_operations.txt | grep "child porn" | gzip
Haskell: return stingops >>= filter (contains "child porn") >>= compress

Now, up till now I've basically ignored Haskell's type system, for the purposes of concentrating on explaining these functions. Without the type system, though, the usefulness of monads completely falls apart: Since the definitions of return and >>= are different for every type that implements them, you can get completely different behavior depending on what type of container (that is, what instance of Monad) you're working with. I'm not going to try to explain why exactly that's the case, because it doesn't really make sense until you actually learn Haskell and see all the different kinds of things that monads are used for. The best I can do in a post on /prog/ is to give you some idea of what the hell you're looking at when you're confronted with one of the batshit monad tutorials strewn all over the internet (there are seriously over 9000 of them). So I didn't explain how to drive, but I did show you what all the pedals are for.

So go actually learn Haskell.

>>34
Yeah, that "double overnight" comment was actually pretty accurate. Real World Haskell came out a couple months ago, and it contains an explanation of monads that doesn't say anything about math and just shows you how they work. #haskell was immediately mobbed by new people who haven't yet gone away.

>>35
Recursion is essentially circular reasoning and hence unscientific and ultimately destructive.

PROVE ME WRONG

PROVE ME WRONG

Back to /b/, please.

>>37
Haskell programmers are double overweight.