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