[SOUND]

Alright in this segment I just want to pick up a few odds and ends that we didnt

do before in the interest of, of getting you ramped up with our useful thing to

know. and thats basically ways to combined

boolean expressions with and, and or, or negation things like that.

And also how to compare numbers with comparison operations I think I've only

shown you equal and grater than so far. So let's start with the boolean

operations. I actually showed you once because it

came up for an algorithm we needed. the construct e1 and also e2.

So, and also is just a seven letter key word.

And the type checking rules are that e1 and e2 can be any expressions that have

type bool. And the evaluation rule is that we

evaluate e1. If we get false, then the result of the

entire thing is false and we never evaluate e2.

Otherwise, we evaluate e2 and then that's the result of the entire expression.

So this is exactly what in most programming languages these days is

written with the && operator. But ML is an older language that chose a

different and longer syntax. So you just have to write out and-also

when you want to do an and like this. similarly we have or-else, where we

evaluate e1, if we get true that's the result for the whole thing and we never

evaluate E2. Otherwise we evaluate E2 and that's the

result for the whole thing. And we have, actually, a function, not,

an OT, that evaluates e1. If you get true, the result is false.

If you get false, the result is true. So again, the syntax is most languages is

different. &&.

a pipe, pipe for or. And the exclamation point for not.

If you try those in ML, they're not going to work.

And, and, and or. And, and or with amper, amper and pipe,

pipe don't mean anything. So you'll get a syntax error.

the exclamation point actually means something totally different related to

mutation, which we might see at the very end.

So you'll get a stranger error message. And the last thing I wanted to point out

is because and also and or else have this property that don't always evaluate both

sub expressions. They really are key words and they're not

functions whereas not can just be a function.

So let me show you that. If I say something like true andalso

false I get false. That's fine.

And if I said true andalso true then I get true.

That's fine. And if I say not true I get false.

And if I say not false I get true. But if I just say andalso.

it's asking for more input. It's like that doesn't make any sense.

That's not the right syntax, this is a syntax error.

Because it says if you use andalso, you have to put an expression on the left and

an expression on the right. But if I just say not, it turns out

that's not special syntax at all. It just says, oh, well that's just a

function that was already defined, that takes a bool and returns a bool.

And that works just fine for not, because we always evaluate it's expression.

But we wouldn't want to define andalso that way, because we know that.

If we have, a function, we evaluate all the arguments to it, before we call the

function. And since that's not the semantics for andalso and or else,

they're not functions. Alright?

Okay. let me just point out one other thing

here. going back to the slides, and that is,

that a language, a programming language, if it has if-then-else expressions, it

doesn't need andalso, or else or not. So it turns out, as you see here on the

slide, if you were ever going to write e1 and also e2, you could just write if e1

then e2, else false. Because both versions have the exact same

type checking rules and semantics. e1 and e2 both have to have type bool.

We evaluate e1. If we get false, that's the type, result

for the whole thing. If we get true, then we get the result of

evaluating E2. Similarly e1 or else e2 could just be

written if e1 then true else e2, and not. Can be written if e1 then false, else

true. So from a how powerful is your language

standpoint all you need is if then else. But because we have and also or else and

not, these longer versions with if then else are considered poor style.

And that's because someone reading your code can tell much more easily, oh this

is and, this is an and or this is an or. If you use the special syntax for it

rather than these more verbose versions using the more general expression.

And as long as we're on the subject. Please make sure that you never, in any

programming language. Write the equivalent of if e, then true,

else false. Let's understand what this is saying.

It says, evaluate e to a result. Which has to be a Boolean.

Either true or false. If that is, result is true, then our

whole thing is true. And if that result is false, then our

whole thing is false. That sounds very natural when you're

programming. But do you know a simpler expression that

has the exact same semantics? E.

E is an expression, that if you evaluate it and you get true, then the whole thing

is true, and if you evaluate it and you get false, the whole thing is false.

So please just write e, not if e then true, else false.

Okay, so those are the Booleans. Let's just finish up with the comparison

operators. If you have two ints, you can see if

there equal of equal. We've done that.

You can see if they're not equal with this second one, the less than greater

than. You might be used to in most programming

languages exclamation point equals. It's just not ML syntax.

You can think of this as < or > if you like.

The other comparison operators are more familiar.

><, <>, >=, <=. Just a couple weird things in ML, thanks

to the type system. And that is that the last four, for

greater than and less than, greater than or equal to, less than or equal to, can

also be used for floating point numbers, which ML calls things of type real, but

you can't use it for an int and a real. So let's just show you what I mean by

that. You can say 3 > 2 you get true.

You can ask if 3.0 is > 2.0. That also gives you true.

Notice, that three has type int and 3.0 has type real.

You can't do this. You just get a type error.

The over need to convert an int to a real, there's a library function that

does that called real.fromint. You can call it with 2, you get back 2.0.

These purple messages are just the ripple telling you that it loaded the library

that has that functionality and you're welcome to ignore that.

Now just one more complication now that I've mentioned reals.

it turns out you cannot in ML, use = or not equal on reals.

You can use them on lots of types, we'll talk about this in the future, things

like equality types. Int's are just one example of an equality

type. But real is not in a quality type its

actually enforcing something that's good in any programming language because

floating point numbers are subject to round off errors it is rarely, rarely the

right thing to do to actually take two floating point numbers and see if they're

equal or not. You should always see if there within

some small epsilon, some small range of each other.