| Assignments | |
| Now | Problem Set 3 |
No class on Thursday.
- Sunday, 18 March (11:59pm) - Email about your project ideas. Send a concise email to evans@cs.virginia.edu describing at least one possible project idea. If you really can't think of anything, describe what you are doing for your research and why you think it has nothing to do with programming languages.
- Week of 19 March - Project idea meetings (schedule on sheet today). Come prepared with something to talk about.
- Tuesday, 26 March - Project proposal. Your proposal should:
- Description of the problem - what will we (meaning the programming languages community) know after you have finished the project that we don't know now? Motivate your project and explain why it is interesting.
- Related Work - this doesn't need to be complete yet, but enough to show the problem is relevant and interesting. You should make sure to relate the related work to your project - why is it relevant to what you want to do?
- Research Plan - concrete description of what you plan to do including a schedule with concrete milestones.
- Evaluation - description of how will you decide if the project is successful.
- Tuesday, 10 April - Preliminary project report.
- Tuesday, 24 April and Thursday, 26 April - Presentations (subject to change).
- Tuesday, 1 May - Final report due.
Your grade on the project doesn't depend on being successful as a research project. For example, if your project involved extending a language with a new feature you might propose to evaluate it by taking some existing programs and rewriting them to use the new feature and comparing the size, performance and readability of the original and rewritten programs. If your experiment concludes that the extension you designed is not a good idea, this does not necessarily reflect poorly on your project grade. In fact, it could be a great project if you can draw conclusions about why it was unsuccessful.
The best projects should lead to conference papers and contribute to your thesis. All project proposals should describe work that could lead to a conference paper if successful.
- B. Liskov, A. Snyder, R. Atkinson and C. Schaffert. Abstraction Mechanisms in CLU. Communications of the ACM, August 1977. (See below for questions on this paper.)
-
Barbara Liskov and John Guttag. Abstraction and Specification in Program Development. Chapter 4: Data Abstraction. 1986.
Required: Sections 4.5, 4.6 and 4.9.4 only. Read the rest if you were confused by parts of the Abstraction Mechanisms in CLU paper.
-
(Optional) B. Liskov and A. Snyder. Exception Handling in CLU, IEEE Transactions on Software Engineering, Nov 1979.
We probably won't discuss this in class, but read it if you want to know how Java should have done exceptions if they had a clu. As you read it, try to identify the key different between exception semantics in CLU and Java.
p. 230: cvt is an unnecessary but useful syntax for making programs more compact. CLU automatically defines:
up = proc (rep) returns (wordbag)Rewrite the implementations of wordbag$create and wordbag$insert without using cvt.
down = proc (wordbag) returns (rep)
p. 231, footnote 3: Explains why it is necessary for wordbag$insert to return a value. Could a different representation be used to make this unnecessary?
p. 231, Figure 4: Unlike Pascal and Algol68, CLU is able to define a recursive data representation without the need for explicit references. What is it about CLU's semantics that allows this? (Hint is on next page.)
p. 232: Is it possible to implement a mutable data type using an immutable representation? Is it possible to implement an immutable data type using a mutable representation?
p. 232: "These restrictions, plus the restriction that only the code in a cluster may use cvt to convert between the abstract and representation types, ensure that the behavior of an object is indeed characterized completely by the operations of its type." Is this correct? Are any other requirements on data type implementations necessary to guarantee this?
p. 233: If you already have experience with an object-oriented language that supports subtyping, consider the differences between subtypes (or Java interfaces) and where clauses. (We'll read a paper on this later.)
p. 234-235: Imagine writing the same program using Java or C++.
p. 236-237: Should data abstraction fundamentally make a program execution slower or faster?
The Abstraction Mechanisms in CLU paper was one of five papers from the Conference on Language Design for Reliable Software held in March 1977 selected for publication in Communications of the ACM. In his introduction to the special issue, Jim Horning writes:
Although the five papers in this special issue are based on particular languages, each raises issues that are of more general concern, and worthy of the attention of anyone concerned with reliable software. They were selected on the basis of their quality, but they also provide a good indication of the major themes of the conference as a whole. The programming community must soon come to terms with the topics that they address, including: What are the qualitative and quantitave effects of strong type-checking? How do verification considerations affect language design? What abstraction mechanisms should languages provide? How can security of high-level languages be extended to real-time applications?How much progress have we made on any of these questions since then? Should we be asking different questions today?
CLU Home Page (including a portable CLU implementation and CLU Reference Manual).
Algol 60 was not only an improvement on its predecessors, but also on nearly all its successors.
|
