

Motivation for Monads - nkurz
http://cs.coloradocollege.edu/~bylvisaker/MonadMotivation/

======
jfarmer
The author of the article buried the lede, which is in the last paragraph:

> _So the tension around types comes from the fact that if you want to program
> in a style that turns effects into explicit things that get passed around,
> sophisticated higher-order functions are necessary to keep your code
> reasonably clean. And sophisticated higher-order functions tend to have
> fancy complicated types. To make programming with them palatable, you either
> need to have a correspondingly fancy type system or punt on types entirely._

I think the author is right when he says "To explain the why of monads, we
have to first explain the why of the functional style of programming."
However, he says one of the "defining characteristics" of the functional style
is that "[f]ancy type systems are important." The net effect of the article is
to give the impression that monads exist because one needs a "fancy type
system" to program with pure functions — as if it were the "fanciness" that
mattered.

We don't have to look hard to understand the "why" of monads. They were
introduced in the paper _Monads for Functional Programming_ by Philip Wadler
([http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...](http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf))
and he spells out the motivations very clearly!

Here was one key to my understanding monads. In a purely functional language
you want everything to be referentially transparent. That is, every expression
should be able to be substituted for its value no matter where it appears. At
the very least, you'll want the ability to denote which parts of your program
are referentially transparent and which aren't.

This can be expressed as utopian vision: in a purely functional language we'd
like everything — _everything_ — to be a value. And if you want expressions
involving functions to be referentially transparent you're going to need pure
functions.

We now need some way of translating code with side effects into code that
returns a value. One reasonable abstraction is to say that the "value" is not
the work itself — once the work is done it's out of the bag, after all — but
rather the "value" is the machine which can perform that work.

~~~
jarcane
What I'm realizing in trying to develop my own (admittedly limited in scope)
functional language is that "fancy type systems", or at least "fancy some-
kind-of-structured-value-thing" systems go a hell of a long way to making it
not an interminable pain in the ass.

The hardest thing for me to "get" about FP is that some problems really do
require an awful lot of persistent data to be easily converted to values to be
passed back and forth instead. Something like, say, a VM, that's a piece of
piss to code in a language that allows mutable state can become an
interminable mess of gobbledygook or just a huge pain in the ass in a lanugage
where the means for passing data structures is too verbose or complicated
(like say, Scheme/Racket structs).

This is why the 'fancy types' in Haskell, I realized, and the robust syntax
for dealing with them. Because they become the main medium for communication
within your program in anything non-trivial, and you need that process to be
as frictionless as possible for the FP approach to not fall apart completely
into a very tedious sort of chaos.

~~~
tel
The other way to look at it is that Haskell allows all of this information
which would be otherwise implicitly embedded in the abstractions, style, and
conventions of a language to float to the top to a formal, verified type
language.

So you can see them as a primary tool to handle the complexity or the driving
force for exposing all the complexity in the first place!

------
barrkel
I don't use monads to split out effects. I use monads because they're a design
pattern that leads to usable, reasonably well-factored APIs, like LINQ and
promises.

Splitting out effects is a different argument. Monads can be (and are in
Haskell) used to evaluate a stateful program from stateless components, but
they're only an implementation detail. But anything with the right shape -
stateless functional holes inserted into the stream between input and output -
would look monadic from the right angle, so I'm not sure there's any escape
from that.

Similarly for using an Option monads for exceptions - and that's what the
Option monad (or closer, Either) ends up approximating, the entire computation
evaluates to None once a bad value is hit, much like throwing an exception
causes the whole computation to evaluate to the exception at the point of the
catch.

So IMO this article isn't really about monads at all.

~~~
benjaminy
Your first paragraph confuses me. Most APIs that I know for promises/futures
are effectful. For example, there is a procedure for checking whether a
promise has been fulfilled yet or not. The return value of this function
obviously depends implicitly on the state of the promise object.

Making this abstraction purely functional requires making the interfaces of
these API functions more complicated. And the monadic style helps reduce that
complexity.

My point is that promises seem very much connected with effects to me, and I'm
curious why you draw a line between them?

(I understand that there are implementations of the monad abstraction that are
not connected with "state" in the conventional sense.)

------
vitd
This was one of the more lucid descriptions of monads I've encountered. I've
tried reading others and they immediately descend into a lot of subtle
language that I don't understand. This really helped.

~~~
visarga
Monads have a lot in common with shell pipes, except for the whole "no side
effects" thing. They are surprisingly familiar to work with.

------
smadge
A monad is a programmable semicolon.

~~~
codygman
Only >> ;)

