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.
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.
Instructor: Raphael Finkel <raphael_at_cs.uky.edu> 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: http://www.cs.uky.edu/~raphael/courses/CS655.html
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.
|1‒10||Chapters in book|
|a||Program 1 due|
|b||Program 2 due|
|c||Program 3 due|
|d||Program 4 due|
|n||No class - Academic holiday|
|r||No class - Religious holiday|
(((4 ()) 6) (((2 3) 4) ()))building a tree, then (b) prints out the tree in outline format, such as
x x x 4 null 6 x x x 2 3 4 nullthen (c) prints out all combinations of 4 leaves, in any order, such as:
4 6 2 3 2 6 2 4 6 2 3 4The program must accomplish step (c) without linearizing the data; it must navigate the in-memory tree.
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.
Submit your programs, project, and final electronically by mailing
If your assignment contains multiple files, please use
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
I will send you back the graded program as an attached
zip file, with my
comments interspersed in lines that contain the word
The time at which you mail the assignment determines whether it is submitted on
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.
There is a checklist of good programming practices at
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.
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.
Policy governing access to and use of University of Kentucky computing resources ,
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.