Syntax and Parentheses

Loading...

En provenance du cours de University of Washington

Programming Languages, Part B

366 notes

University of Washington

Programming Languages, Part B

366 notes

[As described below, this is Part B of a 3-part course. Participants should complete Part A first -- Part B "dives right in" and refers often to material from Part A.] 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 of Part A. Part B assumes successful completion of Part A. 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. 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.

À partir de la leçon

Section 5 and Homework 4 (First Module with Racket)

Let's get started programming with Racket and then learning idioms related to delaying evaluation. The welcome message has a few additional comments about picking up a new language and how to approach the homework assignment, so let's get started...

Rencontrer les enseignants

Dan Grossman
Professor
Computer Science & Engineering

[MUSIC] At this point in our study of Racket, you probably notice that there

are a lot of parentheses. So, in this segment, I want to talk about

why that's actually a good thing in many ways.

And then, in the next segment, I want to teach you how to really think about

parentheses carefully and debug when you make mistakes with your parentheses.

So, ignoring a few bells and whistles, a few corners of the language that we

haven't encountered and won't really focus on,

Racket has an amazingly simple syntax. The way we write programs does not have a

lot of complicated rules. In fact, I can pretty much put them all

on this slide. That's amazing.

So, let's go through what the rules of writing Racket programs are.

So, anything you write in a language, what racket people would call a term is

either some primitive atom, atom as in the word for indivisible, coming from the

Greek, right? So, true and false, I haven't shown these to you yet, but you

write them #t and #f, a number, a string, 4.0, variable names,

these are all atoms. There are also certain atoms that are

special forms. Define is a special form,

lambda, if.

Here, I'm just talking about the words, okay? And when we study macros in the

next section we'll be able to define our own special forms,

that's essentailly what macros are but we'll get there.

So, we have atoms, a very small set of them are special forms and then we have

sequences which is just putting some sequence of terms in parentheses.

So, term is a recursive definition, each of these terms could itself be a sequence

or be an atom or a special form. So, the semantics comes straight from

this syntax as follows, if t1 is a special form, well then, we have

different semantics for each special form, if has a meaning, lambda has a

meaning, define has a meaning, and so on. Otherwise, if t1 is not a special form,

it's not one of these special words, then this is a function call and that's

really it. So, let's do a couple of examples.

If I have + 3 car of xs, this is a sequence with three terms + 3 and car of

xs. Plus, it turns out is not a special form,

so this is a function call just like we expect.

Here, I have a lambda, so I also have a sequence of 3 terms, and I'm missing a

parenthesis here. I'll fix that after I record.

So, I have lambda, then this sequence with the x, then an if, and I should

close this with one more round parenthesis,

okay? Since lambda is a special form, that effects the meaning of the rest of

this. So, this next thing is not a function

call, it's the list of parameters and the thing after that is the function body

which is treated as something that we would evaluate as an expression.

That's really all there is to Racket syntax and it's because of all those

parenthesis that it's so simple. One minor note, as long as we're talking

about syntax, you can also use the square bracket anywhere you use the round

bracket. It's really just a matter of style where

you use square, where you use round, never affects the meaning of everything.

We won't be picky about this, but I will show you a few places where square

brackets are the convention. DrRacket is actually kind of nice on this

one if you're writing a bunch of close parentheses.

don't worry about which kind you're closing.

If you, on your keyboard, hit the round parenthesis, but there's a matching open

square bracket, DrRacket will just change it to a closing square bracket for you.

It's just a convenient keyboard DrRacket thing, okay?

So, why are all these parentheses good? There's a few reasons, but the one I want

to emphasize is that converting the program text into a tree that represents

the program is completely trivial. So, let's go straight to the example you

see here, kind of in the middle of the slide.

Here's one of the version of the cube function we wrote a couple of segments

ago. And when you write it, it's just lines of

text, right? It's just, you know, rows and,

and, and columns of, of characters, right? Parenthesis, define, cube, and so

on. Anything that wants to reason about your

program for compiling it, running it, indenting it automatically for you when

you hit Tab, really wants to think about your program

in terms of this tree. You have defined with two children, cube

and lambda. Lambda with 2 children, the argument and

then the body. This body is just a function call with

star in the first position and then 3 children that, in this case, all happen

to be x. The process of going from the code on the

left to the tree on the right, is incredibly easy when all those

parenthesis are there. This is called parsing in programming

languages speak, taking the string of a program and converting it to the right

tree. And when you have all these parentheses,

it's easy enough that there's never any confusion on the programmers part with

how these things are organized. We simply don't have issues like we do in

other languages of things if you have x plus y times z, is that the tree with

plus at the top or the subtree with the multiplication or is the multiplication

at the top with the plus as a subtree? In other languages, we have to come up with

rules for this. In school, you had to learn the mathematical convention that

multiplication binds more tightly than addition.

But in a syntax like Rackets, just use extra parentheses,

put everything in prefix notation, put the times before its argument,

and there's never a bunch of special rules.

Okay. So, it turns out that people tend to not like this.

I don't mind it. Well, some people do but a lot of people

don't like all these parenthesis. So, let me defend the parenthesis for one

slide. First of all, I never hear anyone

complain about HTML. If you go to a webpage and you look at

the source for that webpage, it takes exactly the same approach.

Instead of things like open parenthesis foo, where foo is some kind of special

form, it actually does something even longer.

It writes foo in angle brackets. It's one character longer.

And then, instead of the closed parenthesis, it's much longer.

It writes a slash and it repeats whatever opened the corresponding thing.

And in HTML, you're not allowed to leave off the closed things.

We don't have a bunch of rules where you get to write plus in the middle, but

other things have to go at the beginning. And yet, no one seems to complain about

this. I agree, at first, it's a little harder

to read. It's nice to have an environment that

colors things and indents things for you. But we have all that for Racket and we

have all that for HTML. And yet, all that, going all the way back

to LISP and Scheme and all these languages that, like Racket, use

parentheses for everything, people seem to have what I would even

call an irrational dislike of them. Now, I can have an irrational like and

you can have an irrational dislike because it's just syntax.

This course is not about teaching you which syntax is good or which syntax is

bad. So, we're allowed to have different

opinions. I can like parentheses and you can

dislike parentheses and that's okay. What I think is inappropriate to do is to

dismiss the entire language of Racket just because you don't like parenthesis.

It has a number of interesting constructs, prospectives, semantics that

we want to study. And even if you don't like parenthesis I

ask you to look past them. The analogy I have on this slide is, it

would be like if someone was a historian and wanted to learn about European

History. So, they wanted to learn all about the

different countries, how they came to be, the wars, the social changes and all

that. But there is one particular country where

they didn't like that people's accent. They found that accent hard to understand

and they wished that people didn't talk like that.

And as a result, they never studied that country's history.

I would argue that that would make you a poor historian.

And dismissing all of Racket just because you happen to not like looking at a bunch

of parentheses on your screen, would make you a bit of a poor computer scientist,

okay? And just to finish up, now that I've been a little vigorous and, and

attacking of people's dislikes or preferences, there is a fun cartoon I'm

linked to here that talks about this age-old issue of there being lots of

parentheses in languages like Racket.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2018 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play