This page gives access to information about the course offerings of ``Programming Languages 1'' as taught (in Spring 1996) by Gary T. Leavens for the Department of Computer Science at Iowa State University.
This is an old offering of the course. Information about the latest offering, with links to others, is also available.
Information is available under the following headings.
Also available (locally at least) are the following.
When I teach this course, I like to change what I teach to some extent each semester. I started teaching (in 1990-92) based on readings, notes, and projects from Dave Gifford's 6.821 course at MIT (for which I was a TA). I gradually found that the students at Iowa State needed more programming experience, and so taught various languages as part of the course (usually towards the end of the semester). At various times these have included: OBJ3, Prolog, lambda-Prolog, Scheme, Standard ML, Haskell, Smalltalk, C++, and SR. (I have also tried to find the right balance between the undergraduate programming languages course, which was been teaching programming and paradigms until Fall 1995, but now teaches some functional programming in Scheme and essential semantic ideas using interpreters.) Continuing the development of 541, I taught the course in 1993 based on Watt's Programming Languages: Concepts and Paradigms, with a supplement of Watt's Programming Languages: Syntax and Semantics; the focus was on language design, not semantics. In 1994 and 1995, I reversed the use of these books, and taught a course centered around semantics, especially for object-oriented programming languages; this version of the course also did a considerable amount of operational semantics, using lambda-Prolog to animate these semantics.
For the Spring 1996 offering, the course will be using Haskell, as a tool for animating denotational semantics, and also David Schmidt's new book The Structure of Typed Programming Languages. I'm struck by how this book uses denotational semantic techniques to explain things (as opposed to teaching the semantic techniques as an end in themselves), and I'm also excited about the way the book combines type theory and semantics.
Computer Science 541 studies modern programming languages, with an emphasis on design and semantics. This document specifies the course's general and specific objectives.
The study of programming languages is primarily concerned with the following questions:
The catalog description of the course is as follows:
Survey of the goals and problems of language design. Formal and informal studies of a wide array of programming language features including type systems, naming, state, and control. Creative use of functional, object-oriented, declarative, concurrent and other programming paradigms. (3 credits).
Com S 541 is distinguished from Com S 342 (Principles of Programming Languages) is that Com S 342 concentrates on essential semantic concepts, studied with the use of interpreters (coded in a functional style). Com S 342 avoids mathematical formalisms, while in Com S 541, we will not shy away from them. In this version of Com S 541, we concentrate on mathematical semantics. In Com S 541 we aim to study modern functional and object-oriented languages, and assume that the graduate students are capable of dealing with the realistic versions of such languages. In Com S 541, we try to use mathematical tools to draw design lessons from our study of semantics, as opposed to simply understanding the features of modern languages.
Com S 541 is distinguished from Com S 641 (Semantics of Programming Languages) in that Com S 641 discusses particular formal semantic description techniques in depth, whereas a broader and less mathematically deep use of semantic description techniques is made in Com S 541; furthermore, an attempt is made in Com S 541 to show how to use these techniques in language design.
Com S 541, ``Programming Languages 1,'' is usually taken by first year graduate students (if they have sufficient background). The class has a ``lecture'' that meets 2 times a week, for 75 minutes a time. It also has a discussion section that meets once a week (for 50 minutes) with a teaching assistant. There are usually 29 or 30 lecture meetings in a semester. The course carries 3 credit hours.
The formal prerequisite in the Iowa State catalog is successful completion of Com S 442 (Principles of Compiling); that is, successful completion of an undergraduate course in compiler construction.
The skills taught in Com S 442 relevant to Com S 541 include the ability to:
At Iowa State Com S 342 (Principles of Programming Languages) is a prerequisite for Com S 442, which means that you should already have some understanding of ``language design concepts,'' ``run-time implementation'' techniques, and ``major features of various programming languages.'' These topics are perhaps more directly relevant to Com S 541 than the material in Com S 442, but at many schools some of these topics are covered in a course on compiler construction. The skills of Com S 342 relevant to Com S 541 include the ability to:
If you do not have this background, especially if you are interested in research in programming languages, you should take Com S 342 or Com S 442 (preferably both if you want to do research in this area). Mere reading of texts on these subjects is not enough.
The general objectives for Com S 541 are divided into two parts: a set of essential of objectives and a set of enrichment objectives. The essential objectives will be helpful for your career as a computer scientist, regardless of your particular speciality; hence you are required to master them to some extent. You are not required to master the enrichment objectives, although you are encouraged to explore them both for their own sake and because learning more about those will help deepen your understanding of the essential objectives.
In general terms the essential objectives for Com S 541 are that you be able to:
You may use reference material to complete these tasks.
Language design is fundamental to mathematics and science because a crucial step in solving a problem is designing an adequate notation for stating the problem (the specification) and expressing the solution. Because computers are general purpose tools, computer scientists, unlike mathematicians and traditional scientists, tend to look at widely different problems. Problems from different application domains often come without a familiar or ready-made notation; thus we computer scientists often find it convenient to develop a special-purpose notation. In developing such a special-purpose notation (e.g., a specification language or programming language) it is helpful to draw on the results of programming language research. These results help you generate plausible designs, avoid errors, evaluate alternative designs, and precisely specify the details of the design. Such justification of a design is a necessary step in convincing yourself and others that your design is good.
Notations that are similar to programming languages are found in every area of computer science. Besides specification languages, other similar notation systems include: user-interfaces, program libraries, formal models of computation, database query languages, operating system command languages and system call interfaces, mathematical logics, computer instruction sets, expert system shells, network protocols, and many others.
In addition, language design is challenging. Since it is one step removed from programming (you design notations that are used by programmers to write many different programs), the opportunities for good or ill are multiplied. Because of that, it is great fun!
Understanding the semantics of major features of programming languages is necessary both to use such features and to design new languages. For example, if you want to program in an object-oriented language you need to understand inheritance and message passing. A better understanding of such features, may help you to better program, reason about, and debug your programs. Formal methods (specification and verification) are becoming increasingly important at many companies, and a deep understanding of the semantics of programming languages is a great help in using formal methods. Without understanding the semantics of such features, you may also have difficulty discussing programming language ideas with others, and will have difficulty in reading the technical literature. If you are planning in specializing in some other area of computer science, you may someday need to read some of the literature on programming languages, either to use results from programming languages, or to apply ideas from your area to programming language research.
Type declarations are a simple form of formal specification, and type checking is a simple, automatic form of program verification. Type checking is believed to be of great help in programming, because it catches errors before a program is run, and type information is used heavily in optimizing compilers to improve generated code. The techniques of type checking can also be applied by hand in dynamically typed languages (like Smalltalk, LISP, or Scheme), and can be used for other purposes (other kinds of static analysis). These techniques are a hot topic of research, and have been so for years. Type systems of programming languages have a deep connection to logic (the Curry-Howard isomorphism). Studying type systems and paying attention to type issues in language design seems to help organize and regularize a language design.
The study of formal semantic description techniques, we believe, helps solidify your understanding of major programming language features. Such techniques are also a valuable tool for language designers. They add precision to descriptions and can be used to help prevent ambiguity. They can also be used to reason about properties of a design, such as whether the design is secure, or whether parts of the language are not useful. But more important, a mathematical model of a language or system can reveal new and interesting possibilities for language features, or the simplification of features. Primitives such as procedure closures, monitors, and continuations first emerged as the result of semantic descriptions. Formal description techniques can also aid in judging language designs, by revealing hidden interactions between features, and by giving you a sense of how simple or complex the design is.
Knowing how to solve problems using the different paradigms is important for several reasons. You can find solutions to problems more surely if you have many different ways to approach problems. In the twenty-first century you will not necessarily be programming in FORTRAN or C; if you can program in a language such as Smalltalk, C++, or Ada, or other new languages you will be much in demand. As parallel programming becomes more important, the use of functional (and declarative) languages may increase. Already the use of functional languages is increasing, and the large telephone company Ericsson uses the functional language Erlang to write all of its software.
Even if you do not become a programmer, the ideas of the functional paradigm (function abstraction, infinite data structures, continuations, referential transparency) have important applications in all areas of computer science and in many other contexts such as mathematics and engineering. Similar comments hold true of the object-oriented paradigm. For example, the idea of data abstraction is certainly a key concept in software engineering and even in contemporary mathematics (category theory).
Enrichment objectives could be multiplied endlessly. Listed here are general statements of those that I tend to teach or that you may wish to investigate. The justification for each objective is included in this list.
Such techniques are essential tools for refining a design, as they permit semantic restrictions to be enforced, and programs to be run.
Understanding the history and the ``state of the art'' in programming language design is important for the following reasons. Knowing the history of language design will help you avoid mistakes and can point out fruitful approaches to solving design problems. Knowing the current research directions in language design helps you avoid spending too much design effort on features that are not well understood; or if you are a programming languages researcher, it tells you places to spend effort. Knowing the goals and problems of language design also helps you categorize problems that may arise in your own work as being in programming languages or elsewhere; this gives you a start towards looking for existing solutions.
This goal may be important for doing successful research in other areas of computer science. Certainly much fruitful research in computer science happens at the boundaries between different areas of computer science. A few examples of interaction between programming languages and other areas: object-oriented databases, capability based operating systems, formal language theory, reduced instruction set computers, data flow computers, type theory, knowledge representation languages.
If you are a programmer, you will probably be programming on a concurrent computer or writing distributed programs during your career. If you are a theoretician, you will surely spend much of your efforts thinking about parallel processing.
There are two required texts: The Structure of Typed Programming Languages by David A. Schmidt (MIT Press, 1994), and An Introduction to Functional Programming Systems Using Haskell by A. J. T. Davie (Cambridge, 1992).
We will also pass out some readings. Other related books are on reserve at the Parks Library.
The syllabus below reflects the 1996 offering of the course. It tells when we discussed the various topics. The ``when'' is specified below by class meeting numbers (a count of the ``lectures,'' which are 75 minutes each).
Essential
Meetings Topic Readings Other Readings
-----------------------------------------------------------------------
1 Introduction (Handouts) S Preface, D Preface
2-8 Functional Programming D 1-4 D 5, 7, 9-10, S 6-7
8-12 Programming Lang. Core S 1
13-19 The Abstraction Principle S 2
15 Test D 1-4, S 1
20-24 Smalltalk handouts Budd/Goldberg @ reserve
25 Test S 2
26-27 OO semantics and design (Handouts)
28-29 Parameters, Correspondence S 3
30 Course Evaluation & Summary