Monads and Gonads

DOUGLAS CROCKFORD: So I'm going to show
you some code today.
Ordinarily, I don't like talks with a lot of code in them,
because I think they're tedious and boring.
And this talk promises to be no exception.
But code is the story.
And so it's not possible to tell this otherwise.
So the topic this morning is monads.
Monads, what are monads?
Monads are this strange, mysterious, weird, but
powerful, expressive pattern that we can use for doing
programming.
And they come with a curse.
The monadic curse is that once someone learns what monads are
and how to use them, they lose the ability to explain it to
other people.
There's lots of evidence of this on the web.
Go and search for monads tutorials, burritos, any of
those things, and you're going to find a lot of really
confusing material.
So today I'm going to attempt to break that curse, and show
you monads for what they actually are.
So we're going to start with functional programming.

If you can't do functional programming, then none of the
rest of this is going to make sense.
But I'm assuming you're all professionals, and this should
not be difficult material.
So there are two senses of the term functional programming.
One of them simply means to program with functions, so
we'll look at that first.
Functions enter mainstream programming with Fortran II.
This is a Fortran II function.
At that time, lowercase hadn't been invented yet, so
everything was in uppercase.
But it looks quite a lot like a modern function.
It starts with the word function.
It has the name of the function, and parameters
wrapped in parentheses, separated by commas--
really conventional stuff.
So it's just a subroutine that had the
ability to return a value.
And it returned that value in a slightly strange way, using
assignment statement, which would assign a value to the
name of the function.
And then the return statement would
deliver that to the caller.
That has been changed since then, and now everybody has a
return statement that takes a value, and that works better.
Or in expression languages, the last expression evaluated
by a function is the implied return value.
But what we called functional programming only becomes
interesting when we have functions
as first class objects.
So we can take a function and pass it as a parameter, or
store it in any variable, or stick it in
the field in a record.
That's when it becomes interesting.
Then we can have higher order functions, in which you have
functions which operate on other functions as arguments.
And this all became really good stuff with the
invention of Scheme.
In Scheme we have what's will closure, which means that any
function has access to the variables
in the outer function.
And it turns out that was an enormous breakthrough.
And that is now finding its way into mainstream languages.
Anyone have any idea which was the first mainstream language
to have this feature?
It was JavaScript.
That's right.
JavaScript is leading the way.
So the other sense of functional programming is
sometimes called pure functional programming.
And it means functions are mathematical functions, which
is quite different than
subroutines that return arguments.
Because a subroutine is allowed to do mutation.
And in a purely mathematical function, that doesn't happen.
A function with some input is always going to
have the same output.
And the argument in favor of that style of programming is
it makes programs a lot easier to reason about, because you
don't have bugs that will occur as a result of side
effects of something else happening.
If something works, it's guaranteed to work that way
correctly until the end of time.
And that could be hugely beneficial.
But there are problems that come with that.
So you could think of mathematical functions as
being maps.
It will simply take some parameter or parameters, and
map them to some value.
And that mapping is constant, and so it
always works that way.
And so it's easy to predict.
So whether functions are implemented as computation or
as association is just an optimization trick.
All functions should work exactly the
same way, either time.
So the difference is like the difference between memoization
and caching.
Caching is a deal with the devil, right?
We have something, which is likely to be wrong but is
sometimes right, and we don't know when it transitions from
being right and wrong.
With memoization, that never occurs.
Once it's memoized it's right and will always be right.

We can take any ordinary programming language and turn
it into a purely functional programming language by
deleting stuff.
So we can remove everything from the language which could
have side effects.
So we could remove the assignment statement.
We can remove loops, and use recursion instead if we need
repetition.
We can freeze all array literals an object literals so
that once minted, they cannot be modified.
In languages like JavaScript, it means removing Date.
Because every time you call Date, it
returns a different value.
That's mathematically absurd.
Every time you call a function, it should return the
same thing.
Same with random.
Every time you call random, you hope to
get a different value.
But that's that doesn't make sense mathematically.
So we want to remove that.
So remove all those things from our languages, then we'll
have purely functional languages, and we'll also find
we're not going to be able to get anything done anymore.
Because most of our programs are not doing pure
computation.
They're interacting with the world.
And the world is constantly changing.
And if our programs can't change with them, then they
become brittle and ineffective.
In the real world, everything changes.
And immutability makes it hard to work in the real world.
Now there are pure functional programming languages like ML,
and like Haskell is a better example.
And Haskell is a brilliant language.
And they were doing interesting computations with
it, and then there was the idea, let's try to do
practical stuff in it.
And then suddenly it gets really, really hard.
That kind of hard is sometimes called impossible, because you
can't have any side effects.
You can't do I/O. How do you interact with things without
being able to do I/O, without being able to mutate?
So they discovered a trick.
There was a loophole in the function contract.
And that loophole is that a function can take a function
as a parameter.
And once it does that, every time a function is called with
a function, every function is going to be different, because
every function is a unique thing, which is closed over
the thing that created it.
And so it sort of gives us a way to escape from the
side-effect-free thing.
You just need to start thinking about how you compose
functions in such a way that you have the illusion of
having mutability without actually mutating anything.
So the Haskell community had reason to adopt something
called the I/O monad, because it gave them the ability to
act as though the language had I/O, even though it didn't.
And so as they're calling things, they can be assembling
state, and that state kind of follows forward in the
computation.
And it kind of works.
It's like, hurray.
It could be used for practical programming, except
it's kind of hard.
And it turns out that you want mutation, because that is how
the world works.
And so the I/O monad is a solution to a problem you
should never have.
But it turns out there are lots of other monads, and so
they're still worth taking a look at.

There's some who will say, in order to understand monads,
you first have to learn Haskell, and you have to learn
Category Theory.
If you don't know these things, there's just the no
way to start.
You can't learn monads.
I think that is true in exactly the same way that in
order to understand burritos, you must first learn Spanish.
And they're true in the same way in that neither is true.
It turns out you can do a lot of stuff with burritos without
knowing any Spanish.
You can order them.
You can eat them, and enjoy them.
You can even learn to make them.
You can even learn to invent new kinds of burritos, which
you and your friends can enjoy.
And you can do that without learning any Spanish.
I'm not saying you shouldn't learn Spanish.
There are lots of good reasons to learn Spanish.
You can learn a lot more about Mexican cuisine, for example.
And that will allow you to make burritos and other
things, which are more authentic, and
perhaps even better.
It'll allow you to have interactions with some
wonderful people you would never interact with otherwise.
And if you're one of the job creators, it gives you an
opportunity to talk directly to the people who are actually
doing your work for you.
That's a good thing, right?
So in the same way, it's good to learn Haskell.
Haskell has a lot of good stuff in it.
It can teach you a lot.
It's a good language to learn.
It's just not necessary to learn Haskell in order to
understand monads.
Some people will disagree with me, and say no, you have to
start with Haskell.
And I say no.
If you have the chicharrones, you can learn
monads without Haskell.

Some people will say, well you at least have to start with
the types, that you need a really strongly typed
language, or a super strongly typed language in order to
manage monads.
You have to understand this before we begin.
And I'm going to tell you, no, that's
actually not true, either.
Haskell has a wonderful type system.
And it does a lot of type inference, so that you can
under-specify what the program does, and it will try to
figure out all the types.
But it doesn't always go right.
And so if it is trying to solve your program, and it
finds an inconsistency, it stops.
And you get this completely opaque message, which is
indicating that it found an inconsistency in a place which
is probably miles away from where the error actually is.
And so getting that stuff to work and compile
can be really hard.
And once it's done, there's folklore which says, having
gone through that ringer, you're guaranteed your program
is going to be error free.
And it turns out it's not, that there are subtle errors
that happen in Haskell, as happen in all other languages.
And the type system actually gives you no leverage in
dealing with that stuff.
Stuff gets complicated, and when there's complexity,
things go wrong.
And that happens in all languages.
It turns out that it's easier to reason about monads if you
don't have to deal with the type stuff.
You don't actually need to understand what that is in
order to build a monad.
Now there's some who will say, no, that's not true.
You don't dare go that way otherwise.
But I say, my friends, if you have the huevos, you can.
So what do you say we sock up and look at some monads?
It turns out, the language you need to learn first is
JavaScript.
Because it has the higher order function
stuff that we need.
And it doesn't have any the type stuff to get in your way.
So you can just think about what's going on.
So what we have here is a story of three functions.
We have a function called unit that takes a value
and returns a monad.
We have a function called bind, which takes a monad and
a function that takes a value that returns a monad.
That's it.
So all three of these functions return
monads, and that's it.
That's monads.
Thank you very much.
So you're probably wondering, still, what is a monad.
A monad is an object in this case.
It could be something else.
But generally it's an object.
So if you know anything about JavaScript, you're looking at
the unit function, you're going, wait, unit is a
function that takes a value and returns an object, so it
must be a constructor.
And yeah, right., that's exactly right.
So unit is constructor.
So nothing magical there.
So all the magic must be in the bind function.
So that's it.
And there's not a lot of magic.
So there are three axioms that you have to hold in order to
be a monad.
The first to describe the relation between bind and
unit, which is basically that unit creates a monad that
represents some value, and the bind function allows another
function to have access to that value.
The interesting axiom is the third one, which tells us how
we can do composition on the bind method--
that we can have nested bind methods, and that does the
same thing as calling bind with a
function that calls bind.
That's it.
That is monads.

Now we can make it easier to deal with these monads by
converting it from functional notation
into methodical notation.
That's a really easy thing to do in JavaScript.
Everybody does that all the time.
You need to understand the mapping between functions and
methods, and once you can do that, then we can very easily
transform the way we invoke the blind method.
Instead of saying bind passing a monad, we'll call the
monad's bind method.
It's just an easier way to do that.

Some languages, say Common Lisp, you would recognize that
there are lots of different possible varieties of monads
that you might want to implement, but they all have
the same basic pattern.
So you'd want to implement some kind of macro to make it
easier for defining all those different kinds of monads.
JavaScript unfortunately does not have macros.
But it does have functions, and so we can create a special
kind of function called a macroid, which acts like a
macro, which helps us to do that kind of
thing that macros do.

So this is one of those macroids.
I want to say something about the coloring.
You've all seen syntax coloring, right?
That's something we put in our text editors to make it easier
for kindergartners to do programming.
Because each of the elements of the language is a different
happy bright color, and so it's easy to recognize, oh
that's a variable, and that's a string, and so on.
I don't get a lot of value out of that because I am more of a
grown up, and I'm a professional programmer.
And I really don't need the colors to figure out what's a
variable and what's a comment.
But when I'm doing functional programming, I would like to
have color help me deal with the nesting of functions, and
deal with the closure.
So I wish someone would make a text editor for
me that does this.
So I want all my global-level stuff to be white.
All the top-level functions, I want them to be green.
The functions defined inside of those would be yellow.
The ones inside of those would be blue, and so on.
But the color of a variable is the color in which it was
defined, and that allows me to see how things close.
It gives me a view of the visibility of the variables
and their life expectancy, and so on.
And that turns out to be really useful stuff.
So I'd really like to have this kind of colorization.
And I'm going to be using this sort of colorization through
the rest of this talk.
So we've got our macroid.
And we're going to use it to define a monad.
And we're going to start with the identity monad.
So the identity monad will build the identity
constructor.
And we'll call the identity constructor, passing it the
"Hello world" string.
And then when we call monad.bind, passing alert, the
alert function as its method, we'll get the
"Hello world" thing.
So this is the simplest slightly useful monad, the
identity monad.

Let's look at the axioms again, using the methodical
notation that we just came up with.
We previously looked at it functionally.
Now we look at it methodically.
And I think it actually makes more sense in this notation.
I think it's easier to see what the relationship between
unit and bind is.
But even better is the thing that happens in composition.
We now have this thing where we've got a monad.
And we call bind.
And it returns another monad.
And we can call bind again.
This is a much easier composition pattern than the
other one, in which we had bind nested inside of bind,
because with the nesting, you have to read the expressions
from the inside out.
And that's a hard thing for us to do.
But in the methodical form, we can read it
from left to right.
And so composition is a lot easier.
I can just keep tacking things on, and the thing keeps
getting longer, and more interesting, more complex.
Any of you who have ever done any Ajax programming might
notice there's something about this pattern that's familiar.
I've got an object.
I call a method on it.
Then I call another method on the result.
Where have I seen that before?
It's the Ajax monad.
All of the Ajax libraries do this--
JQuery, YUI, everybody.
We've been doing this for years.
It turns out we've been doing monads all along.

This is an example of something I did in 2001.
The Interstate library was my third JavaScript library.
The first one was just something to help me manage
the differences between Netscape 4 and IE 4, which
were horrendous.
And after I wrote that, I looked at what sort of
patterns we were using in using it, and then trying to
figure out a way to incorporate more of that into
the library to make it easier to use.
And this is my third iteration.
And in this one I realized that if I have an object which
wraps a DOM node, in this case, a text form node, and if
that object, that monad keeps returning itself, then I can
cascade all of these other things on it.
And it becomes really expressive.
And lots of other people figured this
trick out as well.
And so this is now standard equipment in Ajax libraries.
In 2007, I developed a system called ADsafe which was
intended to make the web safe for doing online advertising.
And it took the same idea of taking a node and wrapping it
in a monadic object, but also added a security
dimension to it.
So it would guarantee that there was no way that the node
could be extracted from the object.
So that meant we could give one of these ADsafe nodes to a
piece of untrusted code, for example, an advertisement, and
be confident that it could not break the containment, that it
was only able to do with that node what we intended it to be
able to do with that node, and nothing else.
It couldn't use it to traverse the rest of the document.
It couldn't use it to get to the network.
It couldn't use it to steal our cookies.
It couldn't do any of those things.
All it could do was display an ad in that window.
And ADsafe worked.
And it used the same monadic pattern.

So let's improve our macroid to allow us to do Ajax stuff.
So we've already seen we can take an object and
call a bind on it.
But what we really want to be able to do is
call a method on it.

Also, we want to be able to have methods pass some
variable number of parameters, as well.
So we'll expand our bind method to now take an optional
second parameter, which is an array of the arguments that we
want to get to the method.
And we'll extend our macroid by first creating a prototype
object, which will be an object which inherits nothing.
This is where we're going to keep the methods of the monad.
We can use object.create of null to make that for us.
It makes an object that inherits nothing.
This is a great new feature that came in the ES5.
And then when we create our monad, we will have it inherit
from that prototype object.
So anything that goes into the prototype object will be
inherited by the monads that we make.
Then we'll modify the blind method to take the second
argument, which is the set of arguments that we want to pass
into the method.
And unfortunately, because of a profound stupidity in the
way JavaScript was designed, we have to manipulate the
arguments object.
And that's really hard, because it
is not a real object.
And so the things you have to do to it are horrible.
Fortunately, ES6, the next edition of the language, will
probably have this dot dot dot operator, which happens to do
exactly the right thing.
This is going to be my second favorite feature in ES6 if it
ever comes out.
So I'm looking forward to that.
Because it took those three extremely ugly lines, and
turned it into one very neat line, which obviously does
what it does.
We're then going to create a unit method on the
constructor, which will allow us to add additional methods
to the prototype.
It simply takes its arguments, and assigns them to the
prototype, so that's pretty easy.
And it also returns unit, so that we can then call dot
method dot method dot method on the constructor.
So it's monadic in that dimension, as well.
But we can do even better than that.
It assumed that the functions that get called to method
understand about monads.
But in some cases we want to be able to wrap functions that
know nothing about monads, but have them work
in the monadic context.
So we're going to add another method to the constructor,
called lift.
And lift will take an ordinary function and
add it to the prototype.
But it will wrap that function in another function, which
will call unit and bind, as suggested in
the first two axioms.
So that it allows that function to act as though it
knew about monads, even though it didn't.
So it'll call bind for us, and it will then wrap it's result
in a monad if it needs to.
So this makes things a lot easier.
So let's use this one.
We're going to call our macroid again to
make our Ajax monad.
And we're going to use lift to turn alert
into a method on it.
So we could change the name here.
But we're going to keep the name the same.
We're going to take the alert function, and use it as the
alert method.
So now I can call the Ajax constructor to make my monad.
And the monad now has an alert method.
And if I call it, it'll say, "Hello world." Hooray.
It turns out we've been doing this for years.
We just didn't know it.
Ajax has always been monadic.

One of the difficulties we have in some of our modern
languages is the problem with null.
Null as the thing that represents a
value that is not there.
And if you try to do something to null, generally something
bad will happen.
Sometimes it seems that Java was optimized for the
generation of null pointer exceptions.
So you end up having--
the null pointer exception doesn't actually ever tell you
anything, except that there was a null that you didn't
check there to avoid.
And so your code tends to get filled with lots of, if null,
don't do that, if null, don't do that.
Which is just a waste of time.
It's completely unproductive.
We knew we didn't want to do that.
We shouldn't have to say so every time we touch a variable
that might want to null.
So there's a thing called the maybe monad.
The maybe monad takes null pointer exceptions and simply
removes them from your model, so you never have to worry
about them anymore.
It's similar to the weight that NaN works.
A long time ago, in Fortran and another languages, if you
ever accidentally divided something by zero, your
program would stop.
Exception, thing crashes, cores, done, stops.
So as a result, you had to write in front of every
division, but if we're dividing by zero,
then don't do it.
You never intended to have it happen, but you had to guard
against it all the time.
So we now have NaN.
And NaN represents Not a Number.
It's sometimes the result of dividing by zero.
And so if we divide by zero, we get NaN instead.
And the program keeps going.
At the end you can ask, by the way, is the answer NaN.
No, OK, something happened.
We can ignore the result.
So that's much nicer than having to put guards around
every operator to make sure that
nothing's going to go wrong.
The maybe monad allows us to do a similar thing with
pointers or references, so we don't have to
worry about that anymore.
Those errors don't happen.
So we're going to modify our macroid in order to be able to
deal with maybe monads.
So we're going to add a parameter to the macro, which
takes a modifier function.
And that modifier function will allow us to intercept
things that we're constructing.
So the unit method, as part of its doing work, will look to
see if the modifier function is present.
And if so, it will call it, passing the
monad and the value.
And that will allow that function that we pass in to do
something with the thing that we're making.

One way we can do that is we can use the macroid to make a
maybe monad by passing in this function, which will look at
the value, and see if the value is null or undefined.
And if it, then we go, this is going to be a null monad.
And it's going to have this amazing property, in that
we're going to change its bind method to do nothing.
It will simply return the monad.
So it turns it into an identity function, and crashes
don't occur.
So now we can make our maybe monad--
this case, we'll make a null one--
and if I call bind on alert, nothing happens.
It's great.
So if you incorporate this kind of stuff into your
system, you never again have to worry about
null pointer errors.
It's just amazing.
They just go away.
Bind will prevent it eve from getting called, and everything
works right, which is nice.
It's a liberating thing.
So that's our friend the monad.
That's it.
And we looked at three specific monads-- the identity
monad, the Ajax monad, the maybe monad.
There are lots more, but they're all
variations on this pattern.
And now that you've been through this talk, you might
want to look at the other monad tutorials.
Go to Bing and Google for monad burrito, and
see what you find.
It's going to be baffling stuff.
But it'll work.
So I have some time left.
So I want to talk about concurrency.
Concurrency is when you try to make lots of things happen at
the same time.
And there are a number of models for how you do that.
The most popular is to use threads.
And the problem with threads is that they are evil with
respect to mutation.
If you have a process that's trying to do read, modify,
write, and another process that's trying to do read,
modify, write, and they're doing it on the same memory,
there's a strong likelihood that they're going to clobber
each other.
That's called races.
And races are horrendously bad for reliability.
The way we mitigate that is with mutual exclusion.
Mutual exclusion has its own set of problems.
It can cause bad performance problems, or more likely it's
going to cause deadlocks and starvation.
And that's a bad thing too.
There are a couple of other alternatives.
One of them is to go with purely functional programming.
Because when we're purely functional, we never mutate.
And so that's not a problem.
But not mutating is its own problem.
Another alternative is turn based processing.
This, I think, is the right way forward.
So in a turn based system, everything is single-threaded.
An as a result we are race free and deadlock free.
That turns out to be great.
But it requires that we respect the law of turns.
The law of turns says, your code must never wait.
It must never block.
And it must finish fast.
A turn cannot sit there and loop, waiting for
something to happen.
It has to get out as quick as it can.
So not all programs can be easily adapted to that.
But it turns out quite a lot of them can.
So event driven systems tend to be turn based.
Message passing systems tend to be turn based.
You don't need threads.
You don't need mutual exclusion.
It's a much simpler programming model, and it's
really effective.
It turns out all web browsers use this model.
Most UI frameworks use this model.
So it's something we've been doing a long time, anyway.
We're now seeing this model getting more popularity on the
server side.
So there's Elko for Java.
There's Twisted for Python.
No JS for JavaScript.
Take the same turn based model, and make it available
on the server.
Now some people complain that asynchronicity
can be hard to manage.
And there are some things you need to do in
order to adapt to it.
One of the problems is that if you have multiple things that
each serially depend on each other, the naive way to write
that is with nested event handlers.
And that turns out to be extremely brittle patterns.
So you don't want to do that.
A much better alternative is to use promises.
Promises are objects which will represent a future value,
and a way of interacting with that future value.
So promises are an excellent mechanism for dealing with
asynchronicity.

Every promise has a corresponding resolver, which
is used ultimately to assign a value to that promise.
And once the value is assigned, then interesting
things can happen.
So a promise, when it's created, will have one of
three states.
First state will be pending.
And depending on what happens to it in the future, it can
change to either kept or broken.
Or it may always be pending.
So a promise is an event generator.
Once the promise is resolved, then it can fire events on
consumers who are interested in the result of the promise.

So at any time after making a promise, an event handling
function can be registered with the promise.
And those will then be called in the order in which they
were registered when the value was known.
And a promise can accept functions that will be called
with a value, once the promise has been kept or broken.
And we can do this with the when method.
The when is sort of like on.
It allows us to register event handlers, but it will register
two of them-- one to be called if the promise is kept, and
the other to be called it the promise is broken.

So here's a function for making up a promise.
I'm calling it vow.
So a vow will produce an object.
And that object will have three methods--
keep, break, or promise.
Promise is not actually method.
It's an object, which represents the promise itself.
So I can take the promise and hand it to you.
And in the future, when I know what the result of that
promise is, I can call either keep or break, and then your
promise will change its state, and good things happen.

So here's an example.
One of the problems with filesystem APIs, going all the
way back to Fortran, is that they block.
If I want to read something from the card reader, or from
the terminal, or if I want to send something to the printer,
or to the disk drive, my program stops until that
operation has completed.
In some cases, my program can stop for a long time.
I don't want to stop, because that breaks the law turns.
The law of turns says I never stop.
I never break.
I have to finish.

A way to do that would be to have the file system, instead
of blocking, it immediately returns a promise.
So my program can then continue going.
I'm not blocked on it.
So here I've got a read file instruction.
Name is probably the name of the file.
And it's going to return a promise.
And I can tell that promise, when you are resolved, call my
success function.
And it will receive the result of the file operation, and
things are good.
And if the file operation failed for some reason, like
file not found, or whatever, then call my
failure function instead.
You might be wondering why do you call my failure function?
Why don't you just throw an exception?
You have to think about this stuff as time travel.
So what an exception does is it unwinds the stack to some
earlier point in time.
And we can then recover from that point.
But in a turn based system, the stack gets reset all the
way down to zero at the end of every turn.
So there's no way I can unwind into a previous turn, because
the stack is gone.
There's no way to go back in time.
You can only go forward in time.
So we need eight time travel mechanism which goes forward.
It turns out promises do that.
That's the whole point.
So promises can have a positive consequence or a
negative consequence.
That negative consequence is like an exception.
So the way we deal with exceptions is by having
failure functions instead, which will be called in the
future, once we know that the thing actually failed.

I think I said all of that.
Exceptions modify the flow of control buy
unwinding the state.
Turn based system, the stack is emptied every turn.

One of the nice things about the way failure functions work
is that we can nest promises.
So each when actually returns another promise, based on the
resolution of that particular when.
And we can cascade those, as well.
So we can say, when we know the result of that, do this.
When we know the result of that, do that.
And so on.
And if any of those fail, and if they don't specify their
own failure, then the failure propagates.
It's contagious.
It goes forward.
And so the last one, the last failure specified, will catch
all of the previous things.
So it acts like a try, except this is something that's
happening over many, many turns.
So it gives us a way to manage asynchronicity.

So one of the nice things about promises and the when
method is how they compose.
So when I say .when.when, that's doing the same thing as
when passing in a function which calls
when on another promise.
And some of you might be thinking, wait a minute, this
looks eerily familiar.
Where have I seen this before?
You might be thinking, this looks like the third axiom.
I would say, you are right.
This is the third axiom.
It turns out promises are monads.
Now they're a different kind of monad, because all the
other ones we've looked at, the value of the monad is
known at the time that it's created.
And because it's purely functional, that value cannot
be modified.
This is a little different, because we don't know the
value at the time that the thing's created.
That's going to be resolved in the future.
So it gets filled in later.
Also because monads don't have the problem where they might
fail to ever get that value, we only need to provide one
function to bind.
But when needs the ability to have two functions, because it
has to deal with a failure case.
But otherwise, it works exactly like the monads.
Let's look at how we could build the vow function in
order to do this.
Now this is about a page worth of code.
And I'll show you the page at the end, but you're not going
to be able to read it.
So I'm going to be zooming in on pieces of it.
So we've got a function that is going to return an object.
And that function is going to have a couple of functions in
it that the yellow function will close over.
That's one of the nice construction
patterns that we have.
And the thing that we're assigned to vow is not the
green function, it's the result of the green function.
Because we're invoking it here, at the bottom.
So that little pair of parens is really easy to overlook.
But it turns out it's really critical to
understanding this.
So just leaving it hanging out there like a pair of dog
balls, I don't think is useful to the reader.
I want the reader to have a bigger clue
that this is important.
So I recommend wrapping the entire implication
expression in parens.
So it makes a lot easier for the reader to see this is all
part of the same thing.
This is important.
If I see a function in parens, that probably means something.
And I need to look for that.
OK, so let's zoom in on the make function.
It's going to have a couple of arrays where it's going to
keep the success functions and failure functions that get
registered with it.
It's going to have a variable for the ultimate fate of this
promise, once it's known.
Its status starts off as pending.
JavaScript doesn't have symbols.
It doesn't really need them, because strings were
implemented correctly.
Two strings containing the same
letters are equal, which--
it would be stupid for them not to be equal, wouldn't it?
And then it returns of an object containing the break
method, the keep method, and the promise
itself, which is an object.
We'll look at its construction in a moment.
And break and keep both call a herald function, which is
going to announce to the world the
resolution of this promise.
So we'll look at herald.
Herald can only be called once.
So if the current state is not pending, then we can throw.
In this case, throwing is OK, because it's a local thing.
It's not something that we need to throw
into a different turn.
We'll set the fate, and we will enlighten the queue of
waiters, and let them know that the fate is known.
And we'll then zero out the two queues to make sure that
none of those functions ever get called again.

So let's zoom in on something else now.
We're going to zoom in on the promise.
The promise will have a property that just identifies
itself as a promise, to make it a little easier to
recognize it.
And it contains the when method.
The when method is going to register the two event
handlers that depend on the result of the promise.
And how it will do that will depend on the current state of
the promise.
If they're pending, then they simply get added to the queue.
If the promise has already been resolved, then it will,
depending on whether we're relying on the failure case or
the other case, will queue it and then enlighten
immediately.
So it doesn't matter when the promise is resolved versus
when we register with the when method.
So there's no race there.
You can register after the promise is resolved, and it
works exactly the same way.
You don't need to care about how that race may occur.
And then at the end, we return the promise.

This is the business that happens when cue the thing.
I'm getting bored now, so I'm just going to skip through
this stuff.
And there's that.
So the code is available on GitHub, if you want
to play with it.
It's all written in JavaScript.
This is it.
There's just one page.
You might want to write that down.

So our friend, the monad.
So we saw the identity monad, the Ajax monad, the maybe
monad, and the promise monad.
I contend that promises are monads, which--
this is my contribution to this, I guess.
I don't think this result had been known before.

Don't forget your semicolons, people.
It's really important.
I've got some further viewing for you.
Carl Hewitt was at MIT.
I think he's at Stanford now.
He came up with the actor model, which inspired the
development of the scheme language, and a
lot of other stuff.
I think the actor model contains the solution to most
of our problems.
But Carl has not written any accessible material about it.
It's all kind of--
you're read it, obviously.
It's scary stuff.
But he did do an interview with
Channel Nine at Microsoft.
It's actually a very nice introduction to the stuff.
So I recommend you take a look at that.
Channel Nine apparently likes the really long URLs.
I doubt that there's anybody in this room who could
actually type that in.
I'm sure if you go search for it, you should be
able to find it.
Then Mark Miller is one of the first people to come up with
promises, which is based on an idea called futures, which
also came out of Carl's actor model.
He's implemented it in a number of languages.
And you just saw an implementation in JavaScript.
He has a really interesting couple of talks that are
available on YouTube, which talk about this, and some of
its implications for doing automated contracting, and
financial instruments, and lots of other really
interesting stuff.
So I recommend you take a look at that as well.
It's certainly worth your time.
And Miller works here, by the way.
He is a Googler, good guy.
And that's it.
That's all I've got for you this hour.
Think you and good night.

MALE SPEAKER: I'm guessing you have a few minutes, maybe to
answer a couple of questions?
In an effort to keep the video in sync with questions, I've
got a lav here.
So I walk around to anybody who wants to ask a question,
just so we can capture it.
And while we're talking about that, nothing
confidential, please.
This will be going public afterwards.
Do you want to start?
AUDIENCE: Thanks for the talk.
I was wondering, what's your take on the
cancellation of promises?
Because that's one of the questions that hasn't been
really resolved.
Cancellation of promises, when I register my listener to a
promise, and I'm not interested
in the result anymore.
DOUGLAS CROCKFORD: So that's a really easy thing to resolve
on your side.
You can have a Boolean at the top of your responder, which
says, am I interested anymore or not.
So you can do it that way.
But promises also compose really nicely.
You can cascade them together and stuff.
So you can have a canceller in that string.
You can compose cancellation.
There are lots of higher level patterns that you can build
out of the simple promises.
AUDIENCE: Is there a way to communicate to the resolver
that you are not interested anymore, therefore it doesn't
need to do the work to generate--
DOUGLAS CROCKFORD: Is there a way to
communicate to the resolver?
Not in the promise system itself.
But you can always send it message.
And it's similar to a problem you might have in, say timers.
You can have a queue of timers.
You might want to say, I'm not interested in this timer
anymore, and so you want to cancel it.
But it might be that by the time you get the cancellation
to it, it's already fired.
So it's likely you're going to experience races.
So that's probably not a pattern you want to pursue.
But it is available to you.

AUDIENCE: It seems that debugging is a real challenge
for turn based programming.
If you set a break point in a conventional program, you can
see the call chain that gave you the context
for why you're there.
You could step over subfunctions, and skip whole
sub trees of the evaluation tree.
And that seems to be a lot more complicated in debugging.
Is there practical tools for debugging turn based programs?
DOUGLAS CROCKFORD: I think it's a lot easier than trying
to debug threads.
The hardest thing I've ever done in my career is try to
debug a real time problem where two threads were chasing
each other.
I think turns are a lot easier to manage than that.
Debugging is always going to be hard.
And as we get more temporal complexity, it gets harder.
But I think turns manage that complexity much better than
threads do.

MALE SPEAKER: As soon as I have the floating mic, I'm
going to make my way to the front in a second.
We've got one more here.
AUDIENCE: Do you have any thoughts on emulating
do-notation in JavaScript?
Have there been any attempts at that?
DOUGLAS CROCKFORD: Thoughts on what?
AUDIENCE: Emulating do-notation?
The monadic do syntax.
DOUGLAS CROCKFORD: No.
One thing we're seeing in JavaScript now is a lot of
experimentation with new syntax.
Coffee scripts launched that--
there were other examples before that.
But there are lots of people who were trying to experiment
with changing language, or making it more expressive.
I expect we'll see that research continue.

We don't see promises as a feature in the
ES6, possibly ES7.
But I'm not confident as to what's going to make in the
ES6 right now.
So it's dangerous to predict what's going to be in seven.
And whether it will bring new syntax with it as well, I
don't know.
AUDIENCE: Is the cost of making closures in JavaScript
make these monadic approaches infeasible right now?
DOUGLAS CROCKFORD: No,
closures aren't that expensive.
They're just function objects.
And they're great.
A lot of stuff gets enabled by this.
You could take a simpler approach to
some of these things.
There is a cost.
But very few of our JavaScript programs are compute bound.
We're mostly bound by everything else.
So I don't think it's a concern.
I think this is easily affordable.

AUDIENCE: Is this a public video?
MALE SPEAKER: Yes.
Any non-competition questions?
You guys are quite a bunch.
All right, I think you stunned into silence, Douglas.
DOUGLAS CROCKFORD: All right.
Thank you.