Here's another sample, how to design 
functions problem. 
In this problem we're going to see a few 
extra wrinkles including an example of 
how not to write a good purpose, some 
problems that can come up with tests and 
some issues having to do with copying 
part of what's in the template. 
Okay, so here's the example. 
I've got to design a function called area 
that consumes the length of one side of a 
square and produces the area of the 
square. 
Let's see, so the length is going to be a 
number, and the area is also going to be 
a number, so the signature is number to 
number. 
And the purpose is given length of one 
side of square comma, produce the area of 
the square. 
There, let me just make a note here about 
what's not a good purpose. 
This is not a good purpose. 
Given number produce number. 
That just repeats the signature. 
That's not telling me something we don't 
already know. 
The purpose needs to tell me something 
more specific than the signature about 
exactly what we do with the given number 
and exactly what the number we produce 
means. 
So, given the length of one side of the 
square, it says this is the length of one 
side of the square produced the area of 
the square. 
This number's going to be the area of the 
square. 
So, that's what we want a purpose 
statement to do is be quite specific 
about what's going on. 
So, now let's see the stub is define 
area, and this is a one argument function 
and maybe the length of a side will be s. 
We can use any name we want, but s seems 
good. 
And let's see, this is producing a 
number, so a good dummy value to produce 
is zero. 
Now let's do some check-expect. 
Let's see, check-expect area 3. 
One side of the square of three, then the 
area is 9. 
Then we'll do another one check expect 
area of, let's say, 3.2. 
And let's see, the area of that square is 
times 3.2. 
3.2., I won't try to do that in my head. 
Now we run the check expects and both 
ran. 
They fail, but they both ran, so that 
means they're well formed, we can 
continue. 
Now let's see, we've got the stub. 
Let's comment out the stub and label it. 
And we'll write the template area of a 
function s, with a parameter s that's a 
number. 
The template is dot, dot, dot s. 
And it's going to be good to have a copy 
of that template, so I'll make a copy of 
it right there. 
We'll comment out the original template, 
we'll label it as the original. 
And now, let's see. 
This is a function that consumes the 
side, and it just multiplies the side by 
itself, so this becomes times ss. 
Let's run that. 
Oh, we've got a failing test here, let's 
see what's happening. 
This says that the actual value nine 
differs from three the expected value and 
I can click to see which test it is. 
Let's see it said it produced nine. 
And oh, here's a thing that happens, this 
test is actually wrong, that's not 
supposed to be three, that's supposed to 
be nine. 
Now if we run it, both tests pass. 
So, there's two interesting things in 
this example. 
One is to note that you need to be 
careful if you get a failing text to make 
sure the test is right. 
If your test is wrong and you make the 
function conform to it then the function 
will be wrong. 
And that happens. 
Sometimes you write a test and you're 
just going a bit too quickly. 
And you put the wrong expected value. 
So when you have a failing test, first 
look at the test to see if the test is 
right. 
The second interesting thing that's 
happening in this example is to see that 
sometimes you have to copy part of the 
template. 
Remember the template for this function 
was dot, dot, dot s. 
And in the final function we ended up 
with s times s and so we copy the piece 
of the template and that's okay. 
The template is really trying to tell 
you, hey, here's the stuff you have to 
work with. 
You can use it in any way you want. 
It's just telling you, this is the parts 
list. 
You can use s twice. 
So there you go, that's our second 
function. 
I'll save it and run it one more time.