[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.
