CS655 is a graduate-level study of the design of programming languages. We will look at features, not complete languages. We will touch on Ada, C++, CLU, Haskell, Icon, Java, Lisp, ML, Modula-2, Modula-3, Pascal, Post, Prolog, Russell, Simula67, Smalltalk, SNOBOL, and others. You will not need to become proficient in any of these languages, but you will learn what contributions each has made to the “state of the art” in language design. Main topics will be control structures, type mechanisms, functional programming, object-oriented programming, concurrent programming, logic programming, and aggregate-based programming. We will also discuss formal semantics of programming languages, particularly denotational semantics. There will be oral and programming assignments and a a written project. There will be no exams.

Learning outcomes

Students will learn about modern programming language design. They will learn about a variety of paradigms and be able to evaluate language features within those paradigms.

People, places, books, and computers

Instructor: Raphael Finkel <>
Office:  Hardymon 230, 7-3885
Office hours:  M 1p-2:30p Th 2p-3:30p
Class time and place: TR 12:30p ‒ 1:45p in MDSB 206
Class web site:

We will use Advanced Programming Language Design by Raphael Finkel (Addison-Wesley 1996, ISBN 0-8053-1191-2)

You will have a class account in the MultiLab ( on the second floor of the Engineering Annex.


The following approximates the grading scale:

40% programs
25% class participation (speaking in class)
25% presenting homework in class
10% the final project (an essay)
I grade on a curve. About half the students get an A, about half B, with an occasional C or E.

You accumulate participation points (1 per class session) if you are present and either ask or answer a question in class or submit a written question immediately after class. There are no other attendance requirements. Let me know in advance if you want accommodation for disabilities or religious observances.

If you are absent when you are to present homework in class, you can still get credit by emailing me your solution before the class starts.

I record extra credit points on a separate tally that I only use after assigning grades, to raise borderline students to the next higher grade. You can lose ordinary points by making mistakes (such as spelling!) in your extra credit work.


Week Th
Aug 22  
Aug 29 2
Sep 5 3
Sep 12 2a  
Sep 19  
Sep 26 3
Oct 3 3b r
Oct 10 4  r
Oct 17 
Oct 24 7c
Oct 31 7
Nov 7 8
Nov 14 9d
Nov 21 9
Nov 28 10 10
Dec 5 10 10e
Code Meaning
1‒10 Chapters in book
Program 1 due
Program 2 due
Program 3 due
Program 4 due
Project due
No class - Academic holiday
No class - Religious holiday

Programming Assignments

  1. Write a program that (a) reads a parenthesized expression representing a binary tree, such as
    (((4 ()) 6) (((2 3) 4) ()))
    building a tree, then (b) prints out the tree in outline format, such as
    then (c) prints out all combinations of 4 leaves, in any order, such as:
    4 6 2 3
    2 6 2 4
    6 2 3 4
    The program must accomplish step (c) without linearizing the data; it must navigate the in-memory tree.
  2. Program polymorphic merge sort, polymorphic insertion sort, and polymorphic selection sort in ML. You must not use ML code you find anywhere on the web. Extra credit: also implement polymorphic heap sort.
  3. Problem 4.19 in the book; code and run.
  4. Problem 5.3 in the book, but include dimensions (as in Section 3.4 of the book) as an attribute of rationals. Implement in both Smalltalk and Java. Extra credit: also implement in Python.

Late penalty

Late work is penalized 3% for each day late, starting at class time on the due date, but not including weekends or holidays. (Allowances for computer failure will be announced in class).  The maximum penalty is 7 days late; after that, you may hand in work and still get 79% until the start of class Thursday of the last week of instruction, which is the absolute deadline. No extra credit is available for work turned in late. If you turn in work early, you gain early points, which offset late points on other assignments but have no other value.

How to submit work

Submit your programs, project, and final electronically by mailing them to If your assignment contains multiple files, please use shar, tar, zip, or rar to create a single file and either include or attach that file. I discard any cover letter, so if you have a README, make sure you place it in the shar, tar, zip, or rar file. I will send you back the graded program as an attached zip file, with my comments interspersed in lines that contain the word “grader” . The time at which you mail the assignment determines whether it is submitted on time. You may prepare your programs on any machine you like; the software you need is available in the MultiLab. I will test your programs on MultiLab machines, so make sure they run there.

Programming standards

Standard rules; There is a checklist of good programming practices at

Presentation: Your program and documentation will have no misspellings. (Yes, I deduct points for spelling.) Your English will be legible, grammatical, and correctly punctuated. You will not have any lines longer than 80 characters. Consult to see how to compose technical prose. I will deduct up to 7 points for presentation errors.

External documentation: Your submittal will come with external documentation. This documentation need not be in a separate file. External documentation includes information for the user of the program (who inhabits the space above the horizontal line in my diagram of a software tool). It tells such a user what the program is intended to do, how to invoke the program, what the program expects as input, and what sort of output to expect. If the program requires compilation, this documentation includes how to compile/link/invoke the program. A Makefile is a valuable way to provide this part of the external documentation. Multiple makefiles are less valuable than a single makefile with multiple targets. I will deduct points for inadequate external documentation.

Internal documentation: Your submittal will come with internal documentation. This documentation need not be in a separate file. Internal documentation includes information for the implementer/maintainer of the program (who inhabits the space below the horizontal line in my diagram of a software tool). It tells how the program does what it does, describing any non-obvious data structures (such as how you represent a closure). It includes comments embedded in the program documenting variables, procedures, and methods. Don't overburden your program with comments, though; a well-written program is mostly self-documenting. I will deduct points for inadequate internal documentation.

Efficiency: Your program will not include needlessly replicated code. It will not include special cases that can be covered by more general cases, unless needed for efficiency and so documented. It will not use inefficient algorithms (in time or space) when efficient algorithms are available.

Test data: Your submittal will come with test data that thoroughly exercise the code and with the expected results of running the program with those test data. You should provide your own carefully constructed test data even if I provide test data. A typescript file is not necessary but can be used to satisfy the testing requirement. I will deduct points for inadequate test data.

Responsible use of computers

Read the Policy governing access to and use of University of Kentucky computing resources , available at . You must respect the privacy of others. You must not attempt to gain access to the files or directories of another user without clear authorization from the other user (typically that authorization is expressed by setting file access permissions to allow public or group reading). You must not attempt to intercept any network communications, such as electronic mail or user-to-user dialog. You must not intentionally interfere with or alter the integrity of the computer systems.


I won't stand for plagiarism or cheating. You may certainly discuss ideas with others, but when you submit a program, it should be entirely your own code. Don't look at each other's code and don't show your code to others. Indicate in your program any code that you worked on with other people or took from any other source. (It is permissible to take algorithms from books, for instance, but you must credit the book.) I will fail you if I catch you violating these standards.