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, FP, Haskell, Icon, 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 written (take-home) final.
This class meets MWF 10:00a - 10:50a in FPAT 263
Instructor: Raphael Finkel http://www.cs.uky.edu/~raphael raphael_at_cs.uky.edu Office: Hardymon 228 Telephone: 7-3885 Office hours: MR 1p-2:30p.
We will use Advanced Programming Language Design by Raphael Finkel (Addison-Wesley 1996, ISBN 0-8053-1191-2)
The class web page is at
http://www.cs.uky.edu/~raphael/courses/CS655.html .
You will have a class account in the Multilab
(http://www.cs.uky.edu/facilities/multilab.php)
on the second floor of the Engineering Annex.
You may also use the CSLab, which is in the Engineering Annex,
second floor.
(Sign up for an account via https://iweb.uky.edu/uams/default.htm.)
Week Date M W F 1 Aug 20 n 1 1 2 Aug 27 1 2 2 3 Sep 3 n 2 2 4 Sep 10 2 3a r 5 Sep 17 3 3 3 6 Sep 24 3 3 r 7 Oct 1 4 4b r 8 Oct 8 4 4 4 9 Oct 15 5 5 5 10 Oct 22 5 7 7c 11 Oct 29 7 7 8 12 Nov 5 8 8 8 13 Nov 12 8 9d 9 14 Nov 19 9 n n 15 Nov 26 10 10 10 16 Dec 3 10 10e 10
Code Meaning 1-10 Chapters in book a Assignment 1 due b Assignment 2 due c Assignment 3 due d Assignment 4 due e Project due n No class - University holiday r No class - Religious holiday
ftp://ftp.cs.uky.edu/cs/software/iters.h),
recursion, and power loops (translated to C via Figure 2.31 in the book).
Programming standards (see below) count.
The following approximates the grading scale:
40% programs 20% class participation (speaking in class) 20% presenting homework in class 10% the final project (an essay) 10% final take-home test (I might not give one)I grade on a curve. About half the students get an A, about half B, with an occasional E or C.
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.
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.
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 class time 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, project, and final electronically by mailing
them to raphael_at_cs.uky.edu.
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, or zip file.
I will send you back the graded program as an attached zip file, with my
comments interspersed in lines that contain the word
``raphael'' .
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 both the CSLab and 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. 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 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. A typescript file is not necessary but can be used to satisfy this 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
http://ukcc.uky.edu/policy.html .
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.