General plan for how the course will go.
Administrative stuff. (Mostly going over the web pages.)
Why should we care about programming languages? (Any examples of big projects without a little language?)
What defines a language?
How important is each of these?
libraries give you the run-time support, not an important part of the language itself. (BTW, the line between “a library” and “part of the language” is less obvious than it seems.)
Yet another example:
How would you expect this code perform? How do you think it does in the reality of many uses of JS by people who are not really programmers?
(+ (vector-ref a 25) 5)(Racket: exception)
-> syntax is mostly in the cosmetics department; semantics is the real thing.
How should we talk about semantics?
A few well-known formalisms for semantics.
We will use programs to explain semantics: the best explanation is a program.
Ignore possible philosophical issues with circularity (but be aware of them). (Actually, they are solved: Scheme has a formal explanation that can be taken as a translation from Scheme to logic, which means that things that we write can be translated to logic.)
We will use Racket for many reasons (syntax, functional, practical, simple, formal, statically typed, environment).
General layout of the parts of Racket:
The Racket language is (mostly) in the Scheme family, or more generally in the Lisp family;
Racket: the core language implementation (language and runtime), written in C;
The actual language(s) that are available in Racket have lots of additional parts that are implemented in Racket itself;
GRacket: a portable Racket GUI extension, written in Racket too;
DrRacket: a GRacket application (also written in Racket);
Documentation: the Racket documentation is your friend (But beware that some things are provided in different forms from different places).
A review of “Goto Statement Considered Harmful”, by E.W. DIJKSTRA
This paper tries to convince us that the well-known goto statement should be eliminated from our programming languages or, at least (since I don’t think that it will ever be eliminated), that programmers should not use it. It is not clear what should replace it. The paper doesn’t explain to us what would be the use of the
ifstatement without a
gototo redirect the flow of execution: Should all our postconditions consist of a single statement, or should we only use the arithmetic
if, which doesn’t contain the offensive
And how will one deal with the case in which, having reached the end of an alternative, the program needs to continue the execution somewhere else?
The author is a proponent of the so-called “structured programming” style, in which, if I get it right, gotos are replaced by indentation. Structured programming is a nice academic exercise, which works well for small examples, but I doubt that any real-world program will ever be written in such a style. More than 10 years of industrial experience with Fortran have proved conclusively to everybody concerned that, in the real world, the goto is useful and necessary: its presence might cause some inconveniences in debugging, but it is a de facto standard and we must live with it. It will take more than the academic elucubrations of a purist to remove it from our languages.
Publishing this would waste valuable paper: Should it be published, I am as sure it will go uncited and unnoticed as I am confident that, 30 years from now, the goto will still be alive and well and used as widely as it is today.
Confidential comments to the editor: The author should withdraw the paper and submit it someplace where it will not be peer reviewed. A letter to the editor would be a perfect choice: Nobody will notice it there!
Racket syntax: similar to other Sexpr-based languages.
Reminder: the parens can be compared to C/etc function call parens —
they always mean that some function is applied. This is the reason why
(+ (1) (2)) won’t work: if you use C syntax that is
+(1(), 2()) but
1 isn’t a function so
1() is an error.
An important difference between syntax and semantics: A good way to think about this is the difference between the string
42stored in a file somewhere (two ASCII values), and the number
42stored in memory (in some representation). You could also continue with the above example: there is nothing wrong with “murder” — it’s just a word, but murder is something you’ll go to jail for.
The evaluation function that Racket uses is actually a function that takes a piece of syntax and returns (or executes) its semantics.
define expressions are used for creating new bindings, do not try to
use them to change values. For example, you should not try to write
(define x (+ x 1)) in an attempt to mimic
x = x+1.
It will not work.
There are two boolean values built in to Racket:
#t (true) and
(false). They can be used in
if statements, for example:
(< 2 3) evaluates to
#t. As a matter of fact, any value
#f is considered to be true, so:
Note: Racket is a functional language — so everything has a value.
This means that the expression
has no meaning when
test evaluates to
#f. This is unlike Pascal/C
where statements do something (side effect) like printing or an
assignment — here an
if statement with no alternate part will just
do nothing if the test is false… Racket, however, must return some
value — it could decide on simply returning
#f (or some unspecified
value) as the value of
as some implementations do, but Racket just declares it a syntax error.
(As we will see in the future, Racket has a more convenient
a clearer intention.)
Well, almost everything is a value…
There are certain things that are part of Racket’s syntax — for
define are special forms, they do not have a value!
More about this shortly.
(Bottom line: much more things do have a value, compared with other languages.)
cond is used for a
else if …
else if …
else … sequence.
The problem is that nested
ifs are inconvenient. For example,
In C/Java/Whatever, you’d write:
(Side question: why isn’t there a
return statement in Racket?)
But trying to force Racket code to look similar:
is more than just bad taste — the indentation rules are there for a reason, the main one is that you can see the structure of your program at a quick glance, and this is no longer true in the above code. (Such code will be penalized!)
So, instead of this, we can use Racket’s
cond statement, like this:
else is a keyword that is used by the
cond form — you
should always use an
else clause (for similar reasons as an
avoid an extra expression evaluation there, and we will need it when we
use a typed language). Also note that square brackets are read by
DrRacket like round parens, it will only make sure that the paren pairs
match. We use this to make code more readable — specifically, there
is a major difference between the above use of
 from the
conventional use of
(). Can you see what it is?
The general structure of a
Example for using an
if expression, and a recursive function:
Use this to show the different tools, especially:
An example of converting it to tail recursive form:
Additional notes about homework submissions:
Begin every function with clear documentation: a type followed by a purpose statement.
Document the function when needed, and according to the guidelines above and in the style guide.
After the function, always have a few test cases — they should cover your complete code (make sure to include possible corner cases). Later on, we will switch to testing the whole file through it’s “public interface”, instead of testing each function.
Lists are a fundamental Racket data type.
A list is defined as either:
the empty list (
a pair (
cons cell) of anything and a list.
As simple as this may seem, it gives us precise formal rules to prove that something is a list.
List operations — predicates:
We can derive
list? from the above rules:
But why can’t we define
list? more simply as
The difference between the above definition and the proper one can be observed in the full Racket language, not in the student languages (where there are no pairs with non-list values in their tails).
List operations — destructors for pairs (
c<x>r combination for
<x> that is made of up to four
ds — we will probably not use much more than
Example for recursive function involving lists:
Use different tools, esp:
How come we could use
list as an argument — use the syntax checker
Main idea: lists are a recursive structure, so functions that operate on lists should be recursive functions that follow the recursive definition of lists.
Another example for list function — summing a list of numbers
Also show how to implement
rcons, using this guideline.
reverse — solve the problem using
rcons can be generalized into something very useful:
How would we use
append instead of
How much time will this take? Does it matter if we use
reverse using tail recursion.
When you have some common value that you need to use in several places, it is bad to duplicate it. For example:
What’s bad about it?
It’s longer than necessary, which will eventually make your code less readable.
It’s slower — by the time you reach the last case, you have evaluated the two sequences three times.
It’s more prone to bugs — the above code is short enough, but what if it was longer so you don’t see the three occurrences on the same page? Will you remember to fix all places when you debug the code months after it was written?
In general, the ability to use names is probably the most fundamental concept in computer science — the fact that makes computer programs what they are.
We already have a facility to name values: function arguments. We could split the above function into two like this:
But instead of the awkward solution of coming up with a new function
just for its names, we have a facility to bind local names —
In general, the syntax for a
let special form is
But note that the bindings are done “in parallel”, for example, try this:
(Note that “in parallel” is quoted here because it’s not really parallelism, but just a matter of scopes: the RHSs are all evaluated in the surrounding scope!)
Using this for the above problem:
Some notes on writing code (also see the style-guide in the handouts section)
Code quality will be graded to in this course!
Use abstractions whenever possible, as said above. This is bad:
But don’t over abstract:
(define one 1) or
(define two "two")
Always do test cases (show coverage tool), you might want to comment them, but you should always make sure your code works.
Do not under-document, but also don’t over-document.
INDENTATION! (Let DrRacket decide; get used to its rules) –> This is part of the culture that was mentioned last time, but it’s done this way for good reason: decades of programming experience have shown this to be the most readable format. It’s also extremely important to keep good indentation since programmers in all Lisps don’t count parens — they look at the structure.
As a general rule,
if should be either all on one line, or the
condition on the first and each consequent on a separate line.
define — either all on one line or a newline after
the object that is being define (either an identifier or a an
identifier with arguments).
Another general rule: you should never have white space after an open-paren, or before a close paren (white space includes newlines). Also, before an open paren there should be either another open paren or white space, and the same goes for after a closing paren.
Use the tools that are available to you: for example, use
instead of nested
ifs (definitely do not force the indentation to
make a nested
if look like its C counterpart — remember to let
DrRacket indent for you).
Another example — do not use
(+ 1 (+ 2 3)) instead of
(+ 1 2 3)
(this might be needed in extremely rare situations, only when you
know your calculus and have extensive knowledge about round-off
Another example — do not use
(cons 1 (cons 2 (cons 3 null)))
(list 1 2 3).
Also — don’t write things like:
since it’s the same as just
A few more of these:
(Actually the first two are almost the same, for example,
(and 1 2)
Use these as examples for many of these issues: