1 | \chapter{Future Work} |
---|
2 | |
---|
3 | \section{Language Improvements} |
---|
4 | \CFA is a developing programming language. As such, there are partially or |
---|
5 | unimplemented features of the language (including several broken components) |
---|
6 | that I had to workaround while building an exception handling system largely in |
---|
7 | the \CFA language (some C components). The following are a few of these |
---|
8 | issues, and once implemented/fixed, how this would affect the exception system. |
---|
9 | \begin{itemize} |
---|
10 | \item |
---|
11 | The implementation of termination is not portable because it includes |
---|
12 | hand-crafted assembly statements. These sections must be ported by hand to |
---|
13 | support more hardware architectures, such as the ARM processor. |
---|
14 | \item |
---|
15 | Due to a type-system problem, the catch clause cannot bind the exception to a |
---|
16 | reference instead of a pointer. Since \CFA has a very general reference |
---|
17 | capability, programmers will want to use it. Once fixed, this capability should |
---|
18 | result in little or no change in the exception system. |
---|
19 | \item |
---|
20 | Termination handlers cannot use local control-flow transfers, \eg by @break@, |
---|
21 | @return@, \etc. The reason is that current code generation hoists a handler |
---|
22 | into a nested function for convenience (versus assemble-code generation at the |
---|
23 | @try@ statement). Hence, when the handler runs, its code is not in the lexical |
---|
24 | scope of the @try@ statement, where the local control-flow transfers are |
---|
25 | meaningful. |
---|
26 | \item |
---|
27 | There is no detection of colliding unwinds. It is possible for clean-up code |
---|
28 | run during an unwind to trigger another unwind that escapes the clean-up code |
---|
29 | itself; such as a termination exception caught further down the stack or a |
---|
30 | cancellation. There do exist ways to handle this but currently they are not |
---|
31 | even detected and the first unwind will simply be forgotten, often leaving |
---|
32 | it in a bad state. |
---|
33 | \item |
---|
34 | Also the exception system did not have a lot of time to be tried and tested. |
---|
35 | So just letting people use the exception system more will reveal new |
---|
36 | quality of life upgrades that can be made with time. |
---|
37 | \end{itemize} |
---|
38 | |
---|
39 | \section{Complete Virtual System} |
---|
40 | The virtual system should be completed. It was not supposed to be part of this |
---|
41 | project, but was thrust upon it to do exception inheritance; hence, only |
---|
42 | minimal work was done. A draft for a complete virtual system is available but |
---|
43 | it is not finalized. A future \CFA project is to complete that work and then |
---|
44 | update the exception system that uses the current version. |
---|
45 | |
---|
46 | There are several improvements to the virtual system that would improve the |
---|
47 | exception traits. The most important one is an assertion to check one virtual |
---|
48 | type is a child of another. This check precisely captures many of the |
---|
49 | correctness requirements. |
---|
50 | |
---|
51 | The full virtual system might also include other improvement like associated |
---|
52 | types to allow traits to refer to types not listed in their header. This |
---|
53 | feature allows exception traits to not refer to the virtual-table type |
---|
54 | explicitly, removing the need for the current interface macros. |
---|
55 | |
---|
56 | \section{Additional Raises} |
---|
57 | Several other kinds of exception raises were considered beyond termination |
---|
58 | (@throw@), resumption (@throwResume@), and reraise. |
---|
59 | |
---|
60 | The first is a non-local/concurrent raise providing asynchronous exceptions, |
---|
61 | \ie raising an exception on another stack. This semantics acts like signals |
---|
62 | allowing for out-of-band communication among coroutines and threads. This kind |
---|
63 | of raise is often restricted to resumption to allow the target stack to |
---|
64 | continue execution normally after the exception has been handled. That is, |
---|
65 | allowing one coroutine/thread to unwind the stack of another via termination is |
---|
66 | bad software engineering. |
---|
67 | |
---|
68 | Non-local/concurrent requires more coordination between the concurrency system |
---|
69 | and the exception system. Many of the interesting design decisions centre |
---|
70 | around masking (controlling which exceptions may be thrown at a stack). It |
---|
71 | would likely require more of the virtual system and would also effect how |
---|
72 | default handlers are set. |
---|
73 | |
---|
74 | Other raises were considered to mimic bidirectional algebraic effects. |
---|
75 | Algebraic effects are used in some functional languages allowing one function |
---|
76 | to have another function on the stack resolve an effect (which is defined with |
---|
77 | a functional-like interface). This semantics can be mimicked with resumptions |
---|
78 | and new raises were discussed to mimic bidirectional algebraic-effects, where |
---|
79 | control can go back and forth between the function-effect caller and handler |
---|
80 | while the effect is underway. |
---|
81 | % resume-top & resume-reply |
---|
82 | These raises would be like the resumption raise except using different search |
---|
83 | patterns to find the handler. |
---|
84 | |
---|
85 | \section{Checked Exceptions} |
---|
86 | Checked exceptions make exceptions part of a function's type by adding the |
---|
87 | exception signature. An exception signature must declare all checked |
---|
88 | exceptions that could propogate from the function (either because they were |
---|
89 | raised inside the function or came from a sub-function). This improves safety |
---|
90 | by making sure every checked exception is either handled or consciously |
---|
91 | passed on. |
---|
92 | |
---|
93 | However checked exceptions were never seriously considered for this project |
---|
94 | for two reasons. The first is due to time constraints, even copying an |
---|
95 | existing checked exception system would be pushing the remaining time and |
---|
96 | trying to address the second problem would take even longer. The second |
---|
97 | problem is that checked exceptions have some real usability trade-offs in |
---|
98 | exchange for the increased safety. |
---|
99 | |
---|
100 | These trade-offs are most problematic when trying to pass exceptions through |
---|
101 | higher-order functions from the functions the user passed into the |
---|
102 | higher-order function. There are no well known solutions to this problem |
---|
103 | that were statifactory for \CFA (which carries some of C's flexability |
---|
104 | over safety design) so one would have to be researched and developed. |
---|
105 | |
---|
106 | Follow-up work might add checked exceptions to \CFA, possibly using |
---|
107 | polymorphic exception signatures, a form of tunneling\cite{Zhang19} or |
---|
108 | checked and unchecked raises. |
---|
109 | |
---|
110 | \section{Zero-Cost Try} |
---|
111 | \CFA does not have zero-cost try-statements because the compiler generates C |
---|
112 | code rather than assembler code \see{\VPageref{p:zero-cost}}. When the compiler |
---|
113 | does create its own assembly (or LLVM byte-code), then zero-cost try-statements |
---|
114 | are possible. The downside of zero-cost try-statements is the LSDA complexity, |
---|
115 | its size (program bloat), and the high cost of raising an exception. |
---|
116 | |
---|
117 | Alternatively, some research could be done into the simpler alternative method |
---|
118 | with a non-zero-cost try-statement but much lower cost exception raise. For |
---|
119 | example, programs are starting to use exception in the normal control path, so |
---|
120 | more exceptions are thrown. In these cases, the cost balance switches towards |
---|
121 | low-cost raise. Unfortunately, while exceptions remain exceptional, the |
---|
122 | libunwind model will probably remain the most effective option. |
---|
123 | |
---|
124 | Zero-cost resumptions is still an open problem. First, because libunwind does |
---|
125 | not support a successful-exiting stack-search without doing an unwind. |
---|
126 | Workarounds are possible but awkward. Ideally an extension to libunwind could |
---|
127 | be made, but that would either require separate maintenance or gain enough |
---|
128 | support to have it folded into the standard. |
---|
129 | |
---|
130 | Also new techniques to skip previously searched parts of the stack need to be |
---|
131 | developed to handle the recursive resume problem and support advanced algebraic |
---|
132 | effects. |
---|
133 | |
---|
134 | \section{Signal Exceptions} |
---|
135 | Goodenough~\cite{Goodenough75} suggests three types of exceptions: escape, |
---|
136 | notify and signal. Escape are termination exceptions, notify are resumption |
---|
137 | exceptions, leaving signal unimplemented. |
---|
138 | |
---|
139 | A signal exception allows either behaviour, \ie after an exception is handled, |
---|
140 | the handler has the option of returning to the raise or after the @try@ |
---|
141 | statement. Currently, \CFA fixes the semantics of the handler return |
---|
142 | syntactically by the @catch@ or @catchResume@ clause. |
---|
143 | |
---|
144 | Signal exception should be reexamined and possibly be supported in \CFA. A very |
---|
145 | direct translation is to have a new raise and catch pair, and a new statement |
---|
146 | (or statements) would indicate if the handler returns to the raise or continues |
---|
147 | where it is; but there may be other options. |
---|
148 | |
---|
149 | For instance, resumption could be extended to cover this use by allowing local |
---|
150 | control flow out of it. This approach would require an unwind as part of the |
---|
151 | transition as there are stack frames that have to be removed. This approach |
---|
152 | means there is no notify raise, but because \CFA does not have exception |
---|
153 | signatures, a termination can be thrown from within any resumption handler so |
---|
154 | there is already a way to do mimic this in existing \CFA. |
---|
155 | |
---|
156 | % Maybe talk about the escape; and escape CONTROL_STMT; statements or how |
---|
157 | % if we could choose if _Unwind_Resume proceeded to the clean-up stage this |
---|
158 | % would be much easier to implement. |
---|