January 24, 2012
This course is intended primarily for students majoring or minoring in computer science or information systems. It assumes CSC 270 as a prerequisite.
In CSC 270, you studied several different languages and paradigms of programming, from the perspective of a programmer using the language. In this course, we'll look "under the hood" at how a programming language works: how do compilers and interpreters represent a program's logical structure, how do they translate between a sequence of characters and that logical structure, how do they resolve variable and function names, how do they enforce data type rules, etc.
This is not quite a "compiler construction" course -- we won't go into great depth on the practicalities of scanning, parsing, code generation, symbol table implementation, optimization, and so on -- but we'll get a taste of those topics, and learn enough about the job of a compiler or an interpreter to understand why particular features of our favorite languages are the way they are. We'll explore different ways those features could work experimentally, by writing interpreters for different versions of a language and seeing how they work. If you do go on to take a compiler construction course, you'll have a very solid grounding in the relevant terminology and issues, and will only need to learn implementation techniques.
You'll also become acquainted with a number of powerful language features you may not have seen before: first-class functions, lazy evaluation, lexical vs. dynamic scope, and continuations. As a bonus, you'll see a very different, and more natural, way to write interactive Web applications.
We'll be using two textbooks. One, Sebesta's Concepts of Programming Languages, should be in the Bookstore (and in the Library, albeit probably an older edition). It's a "classic" programming-languages text, giving a lot of history, a fair amount of theory, and some code examples.
The other main textbook, Krishnamurthi's Programming Languages: Application and Interpretation, is available on the Web for free. This is a very hands-on book, taking the philosophy that you never really understand how a program works until you've implemented it yourself. Accordingly, it leads the reader through the implementation of a series of interpreters for programming languages with various features. The book is on the Web at www.cs.brown.edu/~sk/Publications/Books/ProgLangs/.
We'll also use some on-line sources, such as Learn You a Haskell for Great Good, which despite the name is an extremely readable introduction to the Haskell language.
We'll start by discussing the criteria for a "good" programming language. Of course, different languages are "good" for different purposes; for the purpose of writing interpreters, Racket seems to be especially good, so we'll do most of our programming assignments for the semester in Racket. For those of you who haven't done much Racket programming, or who haven't done it in over a year, we'll spend a few days reviewing Racket and learning some language features that will be particularly helpful in our projects.
The rest of the semester will be "hands-on", working through the implementation of a number of language features in the Krishnamurthi book.
For a detailed, class-by-class schedule of readings and topics, see
There will be about 8 homework assignments, each involving the implementation of some language features, and often with some reflective written questions as well. There will be a two-hour final exam on May 17, from 10:30 AM to 12:30 PM, and there will be a "class participation" component to the grade.
The final exam must be taken at the scheduled time, unless arranged in advance or prevented by a documented medical or family emergency. If you have three or more exams scheduled on the same date, or a religious holiday that conflicts with an exam or assignment due date, please notify me in writing within the first two weeks of the semester in order to receive due consideration. Exams not taken without one of the above excuses will be recorded with a grade of 0.
Every program must contain, in the first few lines, a comment indicating the name of the student(s) working on it and what the program is supposed to do. Programs not containing this information, clearly visible, will get a zero.
Every program must be adequately and accurately commented, as appropriate in the current language.
Programs are not abstract works of art, they are supposed to run and solve real problems. So if I get a program that doesn't compile or run, I will give it a zero, no matter how much time you put into it. Don't bother turning in a program you haven't tested yourself.
I recommend writing most of the programming assignments in teams of two students.
The Adelphi University Code of Ethics applies to this course; look it up on the Web at academics.adelphi.edu/policies/ethics.php .