So, let's have a quick look at the list types.

It is essentially the same as what we have constructed last week.

So, a list with string element is written as list of string, a parametrized type.

So, fruit would be a list of string, numbers would be a list of int, diagonal

three would be a list of list of int. And finally, empty would be a list of

nothing. A list that does not contain elements and is therefore a list of the

bottom type, of as, as element type. Now we've seen lists constructed

homogeneously, refer it in list and just all the elements in the list but in fact,

that's syntactic sugar for something more fundamental.

All lists in Scala are constructed from the empty list Nil and the construction

operation, which is written as a double, double point and is pronounced Cons.

So the operation x cons xs gives you a new list with the first element x and it's

followed by the elements of xs. So that means that our previous, lists of fruit

and numbers and empty can also be written like this.

So fruit would be apples, corns, a list oranges, corns, a list pears and then nil.

That corresponds exactly to what we've drawn in the slide before.

Numbers then would be similarly and finally empty.

The empty list would just be nil. So again note the similarity of what we've

done last week with our simple list hierarchy.

It's just where we were writing new cons x xs.

Now we write simply, x :: xs. In fact, there's a convention for Scala

syntax which makes the cons operation look nicer.

We have the universal convention that all operators that end in a colon associate to

the right. Whereas all other operators would

associate to the left, as usual. So that means that if you have two double

colons like here A :: B :: C then that's really interpreted as A :: and then B :: C

so the parentheses go to the right. And that means when you write a list like

this, you can omit the parentheses because that would be redundant.

So this list really means the same as what we've drawn before with parenthesis going

here, Like that.

The second difference concerning operators that end in colon.

Concerns that raise their scene of method calls.

In fact an operand that ends in a call is seen as a method call of its right hand

operand. Remember all other in fix operators are

seen as method calls on the left hand operands.

So the left hand operand was the receiver. For operaators ending in a colon, this is

reversed, so it's the right hand operand. And that makes a lot of sense, because it

means that an expression like this will really be expanded by the compiler to this

sequence of method courts. So it's Nil followed by the colon

operation, that's a method colon Nil and we pass four as the argument to it.

Then we have another colon method, colon we pass three, then we have another one

and we pass two, and finally, we pass one. So each application of the double colon

cons operation pre-pens the argument to the list that was constructed so far.

So, double colon is really with this convention, the same as the preprened

operation we defined last week. You also know from last week that there

are three fundamental operations on lists. And that all other operations can be

expressed in terms of these three. They are, isEmpty which finds out whether

a list is empty. It returns true if it's empty, false

otherwise. Head, which returns the first element of

the list. Exception if the list is empty. Tail which returns the list compose of all

the elements except the first. So these operations are as you've seen

last week defined as methods on objects of type list.

So for instance you would write fruit.head and get apple or you would write

fruit.tail.head and get oranges. The second element in the fruit list.

If you take the diagonal of size three then its head element would be the first

row. So that would be the list of one, zero,

zero. And if you take head of the empty list,

then you would get an exception. A no such element exception which would

tell you that you have tried to take the head of the empty list.

Its also possible and in fact, often preferred, to decompose lists with pattern

matching. The patterns that you can apply to lists

are exactly the same as the construction methods of lists.

So there will be a middle pattern that corresponds to the middle constant,

there's a cons pattern that has a pattern. And in front of the double colon and the

pattern afterwards. And the idea of that would be that this

pattern matches any list whose head matches P and whose tail matches the

second pattern, PS. And finally there is a short hand list of

P1 to PN, and that's, as usual, the same as the pattern P1 cons P2 and so on cons

PN, and finally, a nil at the end. So, let's see some examples.

The first pattern here would match lists whose first element is a one.

The second element is a two and the rest of the list is arbitrary and is bound to

the variable xs. The second paren.

Here would match lists of length one. And the first element can be arbitrary and

is bound to the variable x. The pattern list of x is exactly the same

as x cons nil. So again, it's lists of length one whose

element is bound to the variable x. The list of open parens., closed parens.,

that's the empty list, the same as nil. And the paren.

List of two colon xs, what would that be? While that would match a list with a

single element which is another list that starts with two and whose tail is bound to

the variable xs. So let's do an exercise.

Consider this list pattern here x cons y cons list xs, ys, cons zs.

What is the condition that describes most accurately the length l of the list it

matches? Does it match lists of length three or

four or five? Or any list that, whose length is greater

or equal to three or greater or equal to four or greater or equal to five?

Well, let's have a look at the pattern again.

So. What we see here is a list of three

elements, the first named x the second named Y, the third is a list by itself.

And then, the rest of the list is captured by the variable zs so that means that the

list. Must have a length that is greater or

equal to three. The variable zed s might be empty, nil, in

which case the list would have a length of exactly three or it might be non-empty in

which case the length of the list would be greater than three.

So in any case the condition that we're looking for would be length greater or =

three. As another example let's suppose we want

to sort a list of numbers in ascending order.

In fact the standard class list in, in the Scala library has a sort function but

let's pretend it hasn't and we have to do it ourselves.

So one way to sort the list say, list of 7392 would be to sort the tail of the

list. 392 sorted would give us list of 239, and

then to insert the head of the list at the right place.

At the right place means that, the, it, it, all elements that precede the inserted

elements are smaller or equal, and all elements that follow are larger or equal.

That idea is insertion sort. So.

We would write it as follows. We would say, well, we have a function I

sort for insertion sort. It takes a list of ints, it gives us back

a list of ints which is the sorted version of xs.

And we would say, okay, if xs is the empty list, then, let's return the empty list.

If xs is a list that consists of at least one element, call that y, and arrest ys.

Then, what we would do is, we would sort recursively the rest, the tail, YS and we

would insert Y into the tail. What you've seen here is by far the most

standard way to decompose a list. You would typically ask first, is the list

empty, and if it's not empty, you would ask, well, what is its head and what is

its tail? And all of these questions are expressed

in the two patterns list of open parens, close parens and the cons pattern that you

see here. So the definition of insertion sort is not

quite done yet because we still have to define the function Insert, that inserts

an element x at the right place of a list x-s which is already sorted.

I'll leave that to you as an exercise. As a hint, we would apply the same

decomposition of lists that we've seen before.

The standard decomposition into a case where the list is empty, and where it's a

cons of a heads and a tail. So all that remains is fill in the triple

question marks here. Once you've done that, I'd like you to

answer the following question. What is the worst case complexity of

insertion sort relative to the length of the input list N?

What I mean by that is what is the number of steps insertion sort performs in our

substitution model as a function of the length of the input list N.

Does sort always take the same amount of time no matter how large N is?

So we would say that sort takes constant time or does sort take a number of steps

that's proportional to the input list N? Or is it maybe proportional to N times

logarithm of N or proportional to N squared?

So lets see how we would answer this. Lets first fill in the insert function.

So inserting an element in an empty list. What would we expect to get back?

Well, that would be the list that contains just the element to be inserted.

Inserting X in a non-empty list, well there would two cases.

The first case would be that the. Element to be inserted is, in fact, less

than or equal to the first element to the list.

In that case, we can simply give you X followed by XS.

So we know that the element X will be the head element of the new list.

Otherwise. What do we need to do?

Well, the first element of our list in the other case where x is greater than y,

would be y, because that's the smallest element of all the elements that we've

seen. And that would be followed by.

Now what we need to do is we need to have a call of insert of x into the remainder

of the list, into y s. So lets look at the complexity.

Now, looking alone at insert first, we see that worst case would be that the element

X is greater than all the elements of the lists.

In which case, we would need N recursive calls for the insert functions.

So the number of steps of insert would be proportional to N where N is the length of

the list. Going back to insertion sort here.

We ask ourselves how many calls to insert would be expect for list of length N.

Well the answer is there would be one call for each element that we have in the list.

So that would be another factor of N. So what we would get at the end is that

the complexity of insert is proportional to N squared.

Which is actually not a good. So we will see in a couple of sessions

another way to sort lists whose complexity is better.