How could we add exceptions and try-catch expressions to Garter? (I.e., assume a complete implementation of Garter, with a working garbage collector, lambdas, sequencing, mutable tuples, tail calls, or whatever other features we’ve considered this semester.) Consider how to “unwind” from the stack frame that throws a value back to whichever stack frame tries to catch it. Consider how to support compositional try-catch blocks (i.e.,

try { try { ... } catch ... { ... } } catch ... { ... }
try { ... } catch ... { try { ... } catch ... { ... } }
try { ... } catch ... { ... } ; try { ... } catch ... { ... }

and other nestings) — note that try-catch can appear in expression positions, and design a semantics for them. Some considerations:

• Your answer must fill in the ... placeholders in the snippet above, and give a grammar for what you intend to support. Those ... are not intended to be the actual syntax someone would write in their program!

• Remember: a semantics should be more precise than just a typical prose description, and more general than a few concrete examples. You should first provide examples to build intuition, and then formulate your semantics as carefully as you can. (Recall how we defined examples and semantics, all the way back in Boa, to introduce how conditionals worked.) You are not required to phrase your semantics in terms of small- or big-step inference rules as we did in class, but you should approach that level of precision.

• Consider what types of values can be thrown and caught by your language. Consider what the evaluated value of these expressions should be. Consider how it interacts with any of our other language features... (Is there a difference in your design between errors and thrown values? Should there be? Could there be? Does it affect any of your semantics?) These interactions easily could influence your design, so work through examples early.

• Do not overly concern yourself with the efficiency of your intended compiled code on this problem; I’m more interested in what expressiveness you can obtain.

• Assume that we take for granted any lexing and parsing changes needed for this new language feature; you do not need to explain how to change the lexer or parser to accommodate them, but you must still define the grammar you want to support.

• Again, be sure to address all the phases of compilation: even if you think some phase is trivial or irrelevant to this problem, mention it explicitly anyway and justify why it’s not interesting or relevant.

What would it take to add a finally { ... } block to these, which runs regardless of whether the try or the catch block ultimately complete? What should the final value of a try/catch/finally expression be? Does your design define a useful semantics for try/finally without any catch clause, or does only the trio together make any sense? Note: a finally clause is not simply something that’s sequenced onto the try or try/catch that precedes it (look up how finally works in other languages to get a sense for what it’s supposed to do). Concretely, try { t } catch { c } finally { f } should not simply be syntactic sugar for try { t } catch { c } ; f

Again, follow the considerations above and explain how this new feature interacts with everything else.