! style="background:#ccddcc;" align="left" | '''''<font color=red>HW6-1 (due Monday, May 6; can think of it as a take-home final, whose weigh is same as a normal HW; choose one of HW6-1 or HW6-2 as main HW, and take the other as extracredit HW, due by May 10)</font>''''' [[Image:downarrow.png]]

+

|-

+

|

+

This HW has only one exercise, but remember that all HWs have equal weight. The exercise is to develop a let-polymorphic type inferencer for FUN.

+

Use the existing syntax of FUN. If correct, your type inferencer should type all the existing FUN programs.

+

+

You are only required to do it using the implicit-constraint style, like in 1_k/5_types/lesson_9.5.

+

+

Several students asked me about extracredit problems. Here is one (50% of a regular HW, but it counts only if you solved correctly and completely HW6-1): Explain why the type inferencer in HW6 is unsound w.r.t. references (yes, it is unsound!), and fix it.

+

+

Note: See the [https://github.com/kframework/k5/tree/master/k-distribution/tutorial/2_languages/3_fun/2_type-inference/exercises/fun-type-inferencer fun-type-inferencer] exercise for details and test programs.

! style="background:#ccddcc;" align="left" | '''''<font color=red>HW6-2 (due Wednesday, May 6; can think of it as a take-home final, whose weigh is same as a normal HW; choose one of HW6-1 or HW6-2 as main HW, and take the other as extracredit HW, due by May 10)</font>''''' [[Image:downarrow.png]]

+

|-

+

|

+

This HW has only one exercise, but remember that all HWs have equal weight. The exercise is to extend LOGIK with several features.

+

+

Note: See the [https://github.com/kframework/k5/tree/master/k-distribution/tutorial/2_languages/4_logik/extended/exercises/logik-extended LOGIK extended] exercise for details and test programs.

+

|}

Revision as of 20:55, 28 April 2019

Students enrolled in this class are expected to check this web page regularly. Complete lecture notes will be posted here.

Course Description

CS422 is an advanced course on principles of programming language design. Major semantic approaches to programming languages will be discussed, such as structural operational semantics (various kinds), denotational semantics, and rewriting-based semantics. Programming language paradigms will be investigated and rigorously defined, including: imperative, functional, object-oriented, and logic programming languages; parameter binding and evaluation strategies; type checking and type inference; concurrency. Since the definitional framework used in this class will be executable, interpreters for the designed languages will be obtained for free. Software analysis tools reasoning about programs in these languages will also arise naturally. Major theoretical models will be discussed.

Exercise 1 (10 points): Modify IMP (its Big-Step and its Small-Step SOS) to halt when a division-by-zero takes place, returning a configuration holding the state in which the division by zero took place.

Exercise 2 (10 points): Add a variable increment construct, ++x (increment x and return the incremented value), to IMP: first add it to the formal BNF syntax, then to the Big-Step SOS, then to the type-system, and then to the Small-Step SOS.

Exercise 3 (10 points): Add I/O constructs, read() and print(AExp) to IMP: first add these to the formal BNF syntax (read() is an AExp construct and print(AExp) is a Stmt construct), then to the Big-Step SOS, then to the type-system, and then to the Small-Step SOS.

Exercise 4 (10 points): Combine the three above: add division-by-zero halting, an increment construct, and the two I/O constructs to IMP.
Feel free to comment on what's going on, particularly on how inconvenient it is to do certain things in SOS (one of the points of this HW is to understand the limitations of SOS, so you will appreciate K).

K Overview paper to learn more about K. Sections 1 and 2 (the other sections are optional now; they are covered below)

HW2 (due Wednesday, February 20)

Exercise 1 (10 points): The current K LAMBDA semantics of mu (in Lesson 8) is based on substitution, and then letrec is defined as a derived operation using mu. Give mu a different semantics, as a derived construct by translation into other LAMBDA constructs, like we defined letrec in Lesson 7. To test it, use the same definition of letrec in terms of mu (from Lesson 8) and write 3 recursive programs, like the provided factorial-letrec.lambda.

Note: See the mu-derived exercise in the nightly built for details and test programs.

Exercise 2 (10 points): Modify the K definition of IMP to not automatically initialize variables to 0. Instead, declared variables should stay uninitialized until assigned a value, and the execution should get stuck when an uninitialized variable is looked up.

Exercise 3 (10 points): Mofify IMP so that the K "followed by" arrow, ~>, does not explicitly occur in the definition (it currently occurs in the semantics of sequential composition). Hint: make sequential composition strict(1) or seqstrict, and have statements reduce to "{}" instead of ".", ... and don't forget to make "{}" a KResult (you may need a new syntactic category for that, which only includes "{}" and is included in KResult).

Note: See the purely-syntactic exercise in the nightly built for details and test programs.

Exercise 4 (10 points): Define a variant of callcc, say callCC, which never returns to the current continuation unless a value is specifically passed to that continuation. Can you define them in terms of each other? Do these in both the substitution and the environment-based definitions.

K Overview paper, which also defines and explains SIMPLE. Sections 3 and 4 (the other sections were covered above)

HW3 (due Wednesday, March 13)

Exercise 1 (10 points): Add "break;" and "continue;" to untyped SIMPLE. Just take the semantics of these
from C/C++/Java, if uncertain. Do only the simple, unlabeled ones, which only break/continue the innermost loop. One thing to think about: do you still want to desugar the for-loop into a while-loop as we do it now?

Note: See the break-continue exercise for untyped SIMPLE in the nightly built for details and test programs.

Exercise 2 (10 points): Our current exceptions in SIMPLE are quite simplistic: the thrown exceptional value
is caught by the innermost try-catch statement, and you get a runtime error (stuck) if the type of the thrown value is not the same as the type of the exception's parameter. They work fine if you restrict them to only throw and catch integer values, like we did in the static semantics, but modern languages do not like this limitation. Change the existing dynamic semantics of typed SIMPLE to propagate a thrown exception to the outer try-catch statement when the inner one cannot handle the exception due to a type mismatch. For example, "try { try { throw 7; } catch(bool x) {print(1};} } catch{int x) {print(2);}" should print 2, not get stuck as it currently happens.

Note: See the typed-exceptions exercise for dynamically typed SIMPLE in the nightly built for details and test programs.

Exercise 3 (10 points): Same as Pb2, but for the static semantics of the typed SIMPLE. For this exercise (but not for the previous one), modify also the syntax of SIMPLE to allow functions to declare what exceptions they can throw.

Note: See the functions-with-throws exercise for statically typed SIMPLE in the nightly built for details and test programs.

Exercise 4 (10 points): Compilers typically collect all the variables declared in a block and move them all in one place, renaming them appropriately everywhere to avoid name conflicts. Consequently, they do not like you to declare a variable twice in the same block. Modify the static semantics of SIMPLE to reject programs which declare the same variable twice in a block. Your resulting type system should get stuck when a variable is declared the second time.

Note: See the no-duplicate-declarations exercise for statically typed SIMPLE in the nightly built for details and test programs.

For each of the problems, also provide one test program which should succeed and one which should fail. You will get two extra-points if any of your tests break everybody's definition (except potentially yours). If you handle more than one succeeding and one failing test, then I will randomly choose one of each.

Exercise 1 (10 points): Currently, all class members (fields and/or methods) are public in KOOL. Sometimes we want to keep members of a class private, in the sense that subclasses do not have direct access to those members. This exercise asks you to add private members to untyped KOOL. Syntactically, you should allow a new keyword, "private", to optionally prepend member declarations. For example, "private var x=10, y=10;" or "private method f(x,y) {...}".

Note: See the private-members exercise for untyped KOOL in the nightly built for details and test programs.

Exercise 2 (10 points): Same as Exercise 1, but for dynamically typed KOOL.

Note: See the private-members exercise for dynamically typed KOOL in the nightly built for details and test programs.

Exercise 3 (10 points): Same as Eercises 1 and 2, but for statically typed KOOL.

Note: See the private-members exercise for statically typed KOOL in the nightly built for details and test programs.

Exercise 1 (10 points): Add a "let*" construct to environment-based FUN. "let*" has the same syntax as "let", but it applies the bindings in the order in which they are given. For example, the program "let* x=1 and y=x in y" is well defined and evaluates to 1, but it would be undefined if we replaced "let*" with "let".

HW6-1 (due Monday, May 6; can think of it as a take-home final, whose weigh is same as a normal HW; choose one of HW6-1 or HW6-2 as main HW, and take the other as extracredit HW, due by May 10)

This HW has only one exercise, but remember that all HWs have equal weight. The exercise is to develop a let-polymorphic type inferencer for FUN.
Use the existing syntax of FUN. If correct, your type inferencer should type all the existing FUN programs.

You are only required to do it using the implicit-constraint style, like in 1_k/5_types/lesson_9.5.

Several students asked me about extracredit problems. Here is one (50% of a regular HW, but it counts only if you solved correctly and completely HW6-1): Explain why the type inferencer in HW6 is unsound w.r.t. references (yes, it is unsound!), and fix it.