This course is an introduction to the basic concepts of programming languages, with a strong emphasis on functional programming. The course uses the languages ML, Racket, and Ruby as vehicles for teaching the concepts, but the real intent is to teach enough about how any language “fits together” to make you more effective programming in any language -- and in learning new ones. This course is neither particularly theoretical nor just about programming specifics -- it will give you a framework for understanding how to use language constructs effectively and how to design correct and elegant programs. By using different languages, you will learn to think more deeply than in terms of the particular syntax of one language. The emphasis on functional programming is essential for learning how to write robust, reusable, composable, and elegant programs. Indeed, many of the most important ideas in modern languages have their roots in functional programming. Get ready to learn a fresh and beautiful way to look at software and how to have fun building it. The course assumes some prior experience with programming, as described in more detail in the first module. The course is divided into three Coursera courses: Part A, Part B, and Part C. As explained in more detail in the first module of Part A, the overall course is a substantial amount of challenging material, so the three-part format provides two intermediate milestones and opportunities for a pause before continuing. The three parts are designed to be completed in order and set up to motivate you to continue through to the end of Part C. The three parts are not quite equal in length: Part A is almost as substantial as Part B and Part C combined. Week 1 of Part A has a more detailed list of topics for all three parts of the course, but it is expected that most course participants will not (yet!) know what all these topics mean.
Booleans and Comparison Operations
Loading...
From the course by University of Washington
Programming Languages, Part A
816 оценки
From the lesson
Section 1 and Homework 1
It's time to dive in! Start with a careful reading of the "Section 1 Welcome Message" and go from there.
Meet the Instructors
Dan GrossmanProfessor
Computer Science & Engineering
[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.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
