[MUSIC] In this segment we're going to start our study of currying, our next
closure idiom. It's one of my favorite things to do in
functional programming. and this is a new way to deal with
conceptually multi-argument function. So you might remember that in ML, every
function takes exactly one argument. We worked around this previously by
passing n arguments as n different pieces of a single tuple.
So another way we could do it which is called currying, is to take one argument
and return a function that takes the next argument and it we'll still be able to
use the first argument, because it will be in its environment.
This is called Currying after the name of the person just as a funniest side, I
actually spent years of my life before I knew that, trying to figure out why it
was called currying, and of course, I was never successful.
So, let me show you an example in the code of how this is going to work.
So, we are going to stick with a very simple example in this section of just a
function that takes three arguments conceptually, x, y and z and sees that
they're sorted. So in terms of tupling, just take a
triple, pattern match against it like this, and return true or false based on
is z >= y and is y >= equal to x. And we would call that tupled function
with a triple like 7, 9, 11. So here is a new way to do it that at
first will seem very ugly, but then I will show you some syntactic sugar that
will perhaps make it even cleaner, even more pleasant than the tupled version.
So let's just make a sorted3 function that takes in an x and returns, these
parentheses are not optional or are optional, so I'm going to take them out,
a function y that when you call it, returns a function z, a function that
takes a z, and when you call it says z >= y and also y >= x.
Now that looks a little funny too, we could have instead said it fun sorted3
taking an x and then return a function y that when you call it, takes a function z
and so on. That's exactly the same thing so maybe
the val version will be a little easier here.
And now, what we can do is we could call sorted3 with a number, like 7 and that
would give us back a function, right? If we call this with x, we're going to get
back this. So what we could then do is call that
function with 9 and that would give us back this function,
and then we could call that with 11. And this will absolutely work and should
even give us the right answer, so let's see.
sure enough I have some lower stuff in the file, ignore that.
sorted3_tupled takes a tuple of ints and returns a bool.
t1 was true. Sorted3 takes an int,
returns a function that takes an int, and returns a function that takes an int, and
that all returns a bool, and then we did use it correctly, and so
t2 is true. So let's take a closer look at what's
going on, because that looks awfully complicated.
It's all the same semantics, we already know about closures.
So when we called (sorted3 7), we got back a closure.
Remember, a closure has two parts, a code and an environment.
The code is just the body of the function we called fn y, fn z, z >= y, and also,
that's the function we got back, we called with (sorted3 7).
It returned this function that takes y and the environment for that closure is
that x maps to 7. So when we call that closure with 9, we get back a closure
whose code is now fn z, z >= y and also y >= x, because that's what the result is
of calling the function with y to 9 and in the environment, x maps to 7 and y
maps to 9. So when we call that closure with 11, we
evaluate the and expression, and we get back true,
that's all there is to it. And, while the semantics may seem
complicated, it's just closures which we get used to.
And since currying is such a common pattern, such a common idiom,
we don't think through it on this level every time.
We just say oh, I'm using currying, so it's like a multi-argument function.
And, so now, let's make it even more pleasant to use by pointing out some
syntactic sugar that we happen to have in ML.
So, it turns out, the first thing we can clean up is this call.
Okay? So we don't need all these parentheses.
In general, if you just leave the parentheses out with spaces between
arguments, the parentheses go in to organize things
to the left. So if you just write sorted3 7 9 11, it's
calling sorted3 with 7, getting back a function and calling it with 9, and
getting back a function and calling it with 11.
So we don't need those parentheses. We can go back to our code here and instead,
just say val t3 = sorted3 7 9 11. And now if you compare this to calling a
tupled function, it's actually fewer characters, more space characters, but
less clutter on the screen, so that's actually kind of nice.
And this is a good time to point out that you have a curried function, like
sorted3, you can call it either of these two ways.
If you have a tupled function, you can only call it this way,
you can't mix and match, right? If you want to call a function
that takes a tuple, you have to pass a tuple.
And if you want to call a function that takes, that's curried, you have do via
via a sequence of calls. So you can't, for example, write
sorted3_tupled 7 9 11. That's going to try to call
sorted3_tupled with 7, you'll get a type error immediately,
because you're not passing a tuple where you need it. And similarly, you cannot
call sorted3 with a tuple, you will also get a type error. It doesn't expect a
tuple, we can see here in the greater than, y >= x, that x needs to be an int
and not a triple int, so we better comment all that out.
Okay? So, so far, so good. That's the first step of syntactic sugar,
is that callers can just think oh, it's curried and takes three arguments.
I'll just separate them by spaces. It's also easier to define curried
functions than I've suggested, that you don't have to write all these
anonymous functions that return other anonymous functions.
That you can, or syntax for function binding has built in support for
currying. So, I have the definitions here written
on the slide, but it is sometimes easier just to show an example.
Here is another definition of sorted3, which I'll call sorted3_nicer.
If you just separate multiple patterns in general, here just variables, before the
equals, this means curried Alright? So y >= x, and so, compared to our
previous version here, these are exactly the same,
this is syntactic sugar for this, although, because we used fn, we could
also use recursion, we don't need recursion here.
So given this that's a much nicer way to write the function, and we can continue
to use it using our syntactic sugar, and that is a really nice way to think of
multi-argument functions. Just the caller, separated them by
spaces, the callee and the caller, separated them by spaces, but what is
going on semantically is closures, functions returning other functions,
the rest is just syntactic sugar. I would point out that because this is
just syntax, you could call sorted3_nicer with all these parentheses, because this
means exactly the same thing as the line and a buff, 'kay? So that is what most of
what I wanted to show you. Remember here, over in the over in SML,
in ripple, that these tupled functions will print their arguments looking like
this, sorted3_nicer, we'd have exactly the same
type. Remember, the parentheses go to the right
here, so this says, I'm a function that takes
an int and returns an int -> int -> bool. meaning that you passed that function in
int and you get back a function, you pass that function in int and you'll get back
a bool. So as you can, here in the alpha to the
ripple, I had one more thing I wanted to show you,
which was a fold in a curried form. So we've seen fold before, it was a
couple of segments ago. Here is a version that takes three
curried arguments using our syntactic sugar. So this first line right here that
I'm highlighting, means exactly the same thing as on a function fold that takes f
and returns a function that takes the accumulator.
If you call that, it returns a functions that takes x's and this is its body. And
you'll notice that here in the recursive call, since I have a curried function, I
need to pass those arguments separated by spaces and I've done that.
Here is the first argument, here is the second argument, and you need
these parentheses so that you know where the second argument ends and this third
argument begins. So that's a perfectly fine curried
function. Here is a use of it.
Here is a function that sums all the elements in a list by just calling fold,
which here is curried. Here's the first argument, space, second
argument, space, third argument, exact same semantics as sorted3,
just more useful. So, coming back here, in terms of
sorted3, our final version here is really very elegant.
It's actually fewer non-space characters than the tupled approach, the approach
that used tuples, and we just know that it's syntactic
sugar for this bottom version, which is easier to understand what's going on.
But once you get it, once you go oh, that's what curring is doing,
then you just think of it as a three argument function, like we've thought of
tuples as multi-argument functions. And then for fold, we just write it this
way to begin with. It's just as elegant.
We think of fold as a three argument function and we call it with three
arguments.
