Due: Friday, December 11th, 2020 11:59pm
Submit your work by scheduling a meeting with the instructor (link), preferably at a time well before the due date. You’ll show your code and answer questions in the meeting. You don’t need to handin your code at all, other than showing it at the meeting.
Start with the typed-class interpreter and typechecker: typed-parse.rkt. typed-class.rkt, inherit.rkt. inherit-parse.rkt. and class.rkt. Since you won’t use the “Handin” button to submit your work, there’s no need to collapse the modules into a single file.
Implement some of the follow additions, which are of varying difficulty. Each addition is annotated by a star rating; implement enough additions so that the sum of the star ratings is:
Extra credit will be awarded for rating sums beyond the required level, where the extra-point value of an extra star wll be 50% of the point value of a required star (e.g., 16 ★s would be 150% for a CS 3520 student).
| ★ 1. | Add a {cast <Symbol> <ExpI>} form to the language. At run-time, the cast expression reports an error if <ExpI> does not produce an instance of <Symbol> or one of its subclasses. Otherwise, the result is just the result of <ExpI>. Of course, <Symbol> should generally be a subtype of the type for <ExpI>, and the type checker can assume that the {cast <Symbol> <ExpI>} has type <Symbol>. The type-checker must reject the expression if the type of <ExpI> is neither a subtype nor supertype of <Symbol>, since the cast cannot succeed in that case. (Note: “subtype” and “supertype” here are reflexive relations.) |
| ★★ 2. | Add an {if0 <ExpI> <ExpI> <ExpI>} form to the language, where if0 requires a number for the test expression. The “then” and “else” branches should both have a type that is a subtype of some most-specific third type: one that is a subtype of any supertype of both the “then” and “else” types, which you might call the “least upper bound” of the “then” and “else” types. (Note: “subtype” and “supertype” here are reflexive relations.) |
| ★★ 3. | Add a local-binding expression form like {let {[<Symbol> : <Type> <ExpI>]} <ExpI>}, but you can pick whatever syntax you like. You’ll need to also allow identifiers as expressions, and your typechecker must ensure that there are no free identifiers. Also, allow the argument name for a method to be something other than arg. Disallow this as a local variable name or as an method argument name. |
| ★★ 4. | [Pre-requsite: 3] Allow fields to referenced directly within a method (i.e., using the field name as an expression instead of using a get form). For example, in a class has a size field, then size as an expression within a method refers to that field. Methods in a subclass should be able to directly reference fields declared in superclasses; you can assume that all field names are distinct. Method and local-variable names should shadow field names; for example, if a method of a class has a size argument, then size as an expression refers to the argument of the method, and a size field would only be accessible within the method using {get this size}. |
| ★★ 5. | Add imperative field assignment to the language. That is, in addition to the {get <ExpI> <Symbol>} form, add a {set <ExpI> <Symbol> <ExpI>} form that sets the value of the indicated field. (Hint: the value for each field in an object must be placed in a box.) Update the typechecker to ensure that the field is always available for the assignment, and to ensure that the type of the second <ExpI> in a set form is a subtype of the field’s type. Your test suite must include a test that would fail with a functional implementation of field assignment (i.e., one where assigning to a field produces a new object) and pass with an imperative implementation of update. That test must be just a Curly program; trying to use begin or let at the Plait level will not work. If you don’t implement local binding, then constructing the test is challenging, but not impossible. |
| ★★★ 6. | Add Java-style object arrays to the language with the forms {newarray <Type> <ExpI> <ExpI>}, {arrayref <ExpI> <ExpI>}, and {arrayset <ExpI> <ExpI> <ExpI>}.
|
| ★★ 7. | [Pre-requisite: 6] As in Java, allow array-of-<Type>1 to be a subtype of array-of-<Type>2 when <Type>1 is a subtype of <Type>2. A run-time check must be added to arrayset to ensure that an instance of a class is not installed into an array that requires subclass instances. |
| ★★ 8. | Add a Java-style null expression and value to the language. A null value can be used like an object, except that attempting to call a method or get (or set) a field of null produces a run-time error. The typechecker should ensure that null is never used like a number. The typechecker can reject expressions when null is used directly as a method or field source, as in {get null x} or {send null m 0}, but null should always be allowed as a non-number method argument or non-number field value. For example, if a method expects an object of some type, then the typechecker should allow null as an argument to the methods; if the method doesn’t try to access any fields or call any methods on the object, it should run without error. |
| ★★★★★ 9. | Add Java-style interfaces to the language. An interface is a set of method names, and it is a subinterface of an arbitrary number of other interfaces (in which case the interface includes all of the methods of its superinterfaces). A class implements any number of interfaces, and it is obliged to implement every method that is named in its implemented interfaces; the class is then a subtype of the interface. The type language is extended to include interface names in addition to class names and num. |
| ★★★★★★ 10. | Add Java-style overloading, where multiple methods can have the same name as long as they have different argument types. Usually, this is implemented by having the type-checker convert the input program to replace the original method names with names that describe the argument types. |
| ★★★★★★ 11. | Add Java-style generics, which are a form of parametric polymorphism. A generic class is parameterized with respect to a type variable, and whenever the generic class name is used, a specific type for the parameterization must be supplied. Consult a Java reference for more information; ignore Java’s support for generic methods and for using a generic type directly as a type (which is for backward compatibility only). |
| Last update: Wednesday, November 25th, 2020mflatt@cs.utah.edu |