

Monads, Zippers and Views: Virtualizing the Monad Stack - buro9
http://ropas.snu.ac.kr/~bruno/papers/VirtualMonads.pdf

======
01PH
42 Votes and I have no idea what this is all about. Can somebody please give
us a summary for the "uneducated" ;)

~~~
viscanti
Monads offer a level of abstraction over non-functional parts (anything that
might have side effects) of a functional program. In functional programming,
the idea is that every time you put something into a function, you should get
the same result (i.e. every time you put a 5 into a doubling function, you get
a 10). A byproduct of that simple idea, is the possibility of extreme
complexity, and thus the reason for an extra level of abstraction. It's easier
for many to reason about this potential complex behavior at a higher level.

This article talks about some of the options of adding an additional level of
abstraction on top of the monad. The idea is that some people find it
difficult to reason about monads, because they have so many specific
applications (read 10 monad articles and you'll get 10 different definitions
for what they are).

TLDR: It's an abstraction of an abstraction that might help you reason better
about complex things.

~~~
zdw
Thank you for this - the first sentence helped immensely.

~~~
Rusky
And is also grossly wrong (or to put it more charitably, over-specific). The
only monad that has to do with side effects is IO, and that's a special one
built into the language.

Haskell's do-notation could almost be said to abstract side effects because it
makes monad actions look like imperative programs, but they're still pure-
functional unless they're in the IO monad.

~~~
viscanti
It is overly specific, but it's probably the easiest to understand explanation
for someone who is familiar with imperative programming. Concurrency,
continuations and exception monads are all likely more difficult to grasp.

A more accurate explanation would say that monads are just an abstraction that
encapsulates program logic. Someone unfamiliar with the concept might not see
WHY that's important. So my example was tangible, but not all inclusive.

One of the big issues with abstract concepts like monads, is that most people
insist on using a long-winded complex explanation up front. I find it's better
to pique interest, and make the concepts accessible, with the hope that the
reader later is willing to dig in and learn more themselves. I probably could
have done a better job of explaining that the IO monad isn't the only monad,
but I think it did a "good enough" job of explaining a way to think about
them.

~~~
Rusky
This is a good point of view to come from. I just think it's important to
emphasize two things, to avoid the monad-insanity that people often get- 1) IO
is not the only monad, and 2) monads are not the only, or even best, of this
kind of abstraction.

Learning about monads without (applicative) functors makes everything look
like an over-complicated nail.

