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, JavaScript, Go, 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 some 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, time permitting, aggregate-based programming. We will also discuss formal semantics of programming languages, particularly denotational semantics. There will be oral and programming assignments and 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.
Class: | MWF 11:00p ‒ 11:50p in FPAT 263 |
Instructor: | Raphael Finkel <raphael_at_cs.uky.edu> |
Office: | Hardymon 230, 7-3885, Zoom 581609732 |
Office hours: | T 10a-11:30a, Th 2p-3:30p |
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
(https://www.cs.uky.edu/docs/users/multilab.html
).
This class will not use a VM.
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 | Date | M | W | F |
1 | Aug 23 | 1 | 1 | 2 |
2 | Aug 30 | 2 | 2 | 2 |
3 | Sep 6 | n | r | 3a |
4 | Sep 13 | 3 | 3 | 3 |
5 | Sep 20 | 3 | r | 4 |
6 | Sep 27 | 4 | r | 4 |
7 | Oct 4 | 4 | 4 | 4b |
8 | Oct 11 | 5 | 5 | 5 |
9 | Oct 18 | 5 | 5 | 7c |
10 | Oct 25 | n | 7 | 7 |
11 | Nov 1 | 7 | 7 | 8 |
12 | Nov 8 | 8 | 8 | 9d |
13 | Nov 15 | 9 | 9 | 9 |
14 | Nov 22 | 9 | n | n |
15 | Nov 29 | 10 | 10 | 10e |
16 | Dec 6 | 10 | 10f | n |
Code | Meaning |
1‒10 | Chapters in book |
a | Program 1 due |
b | Program 2 due |
c | Program 3 due |
d | Program 4 due |
e | Project due |
f | Last day to turn in assignments |
n | No class - Academic holiday |
r | No class - Religious holiday |
(((5 ()) 6) (((2 3) 4) ()))building a tree, (b) prints out the tree in outline format, such as
x x x 5 null 6 x x x 2 3 4 null(c) prints out all combinations (order-independent) of 4 leaves, such as:
2 3 4 5 2 3 4 6 2 3 5 6 2 4 5 6 3 4 5 6The program must accomplish step (c) without linearizing the data; it must navigate the in-memory tree. You should use recursive iterators. I suggest you use Python, but you may use Icon or JavaScript instead. Extra credit: Accept on the command line the size n of combinations, generalizing from 4 to any non-negative integer.
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 Wednesday 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 and project electronically by uploading to Canvas.
If your assignment contains multiple files, please use shar
, tar
,
zip
, or rar
to create a single file to upload.
I will return your graded program as a zip
file, with my
comments interspersed in lines that contain the word
“grader” .
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.
Standard rules;
There is a checklist of good programming practices at
http://www.cs.uky.edu/~raphael/checklist.html
.
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
http://www.cs.uky.edu/~raphael/writing.html
to see how to compose technical prose.
I will deduct up to 5 points for presentation errors.
External documentation:
Your submittal will come with external documentation. This documentation
need not be in a separate file, but it is most convenient to put it in a README
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.
Read the Policy governing access to and use of University of Kentucky computing resources , available at
https://www.uky.edu/regs/sites/www.uky.edu.regs/files/files/ar/ar10-1.pdfYou 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, including classwork from other courses or the Internet. It is permissible to take algorithms from books, for instance, but you must credit the book.
Students are expected to follow University policy regarding Covid safety
requirements.
The material in https://www.uky.edu/universitysenate/acadpolicy
,
https://www.uky.edu/universitysenate/ao
,
and
https://www.uky.edu/universitysenate/student-resources
is
included here by reference.