[a032992] | 1 | \chapter{Future Work} |
---|
| 2 | |
---|
| 3 | \section{Complete Virtual System} |
---|
| 4 | The virtual system should be completed. It was never supposed to be part of |
---|
| 5 | this project and so minimal work was done on it. A draft of what the complete |
---|
| 6 | system might look like was created but it was never finalized or implemented. |
---|
| 7 | A future project in \CFA would be to complete that work and to update the |
---|
| 8 | parts of the exception system that use the current version. |
---|
| 9 | |
---|
[02b73ea] | 10 | There are several improvements to the virtual system that would improve |
---|
| 11 | the exception traits. The biggest one is an assertion that checks that one |
---|
| 12 | virtual type is a child of another virtual type. This would capture many of |
---|
| 13 | the requirements much more precisely. |
---|
| 14 | |
---|
| 15 | The full virtual system might also include other improvement like associated |
---|
| 16 | types. This is a proposed feature that would allow traits to refer to types |
---|
| 17 | not listed in their header. This would allow the exception traits to not |
---|
| 18 | refer to the virtual table type explicatly which would remove the need for |
---|
| 19 | the interface macros. |
---|
[a032992] | 20 | |
---|
| 21 | \section{Additional Throws} |
---|
[f28fdee] | 22 | Several other kinds of throws, beyond the termination throw (@throw@), |
---|
| 23 | the resumption throw (@throwResume@) and the re-throws, were considered. |
---|
[a032992] | 24 | None were as useful as the core throws but they would likely be worth |
---|
| 25 | revising. |
---|
| 26 | |
---|
| 27 | The first ones are throws for asynchronous exceptions, throwing exceptions |
---|
| 28 | from one stack to another. These act like signals allowing for communication |
---|
| 29 | between the stacks. This is usually used with resumption as it allows the |
---|
| 30 | target stack to continue execution normally after the exception has been |
---|
| 31 | handled. |
---|
| 32 | |
---|
| 33 | This would much more coordination between the concurrency system and the |
---|
| 34 | exception system to handle. Most of the interesting design decisions around |
---|
| 35 | applying asynchronous exceptions appear to be around masking (controlling |
---|
| 36 | which exceptions may be thrown at a stack). It would likely require more of |
---|
| 37 | the virtual system and would also effect how default handlers are set. |
---|
| 38 | |
---|
| 39 | The other throws were designed to mimic bidirectional algebraic effects. |
---|
| 40 | Algebraic effects are used in some functional languages and allow a function |
---|
| 41 | to have another function on the stack resolve an effect (which is defined with |
---|
| 42 | a function-like interface). |
---|
| 43 | These can be mimiced with resumptions and the the new throws were designed |
---|
| 44 | to try and mimic bidirectional algebraic effects, where control can go back |
---|
| 45 | and forth between the function effect caller and handler while the effect |
---|
| 46 | is underway. |
---|
| 47 | % resume-top & resume-reply |
---|
| 48 | |
---|
| 49 | These throws would likely be just like the resumption throw except they would |
---|
| 50 | use different search patterns to find the handler to reply to. |
---|
| 51 | |
---|
| 52 | \section{Zero-Cost Exceptions} |
---|
| 53 | \CFA does not have zero-cost exceptions because it does not generate assembly |
---|
| 54 | but instead generates C code. See the implementation section. When the |
---|
| 55 | compiler does start to create its own assembly (or LLVM byte code) then |
---|
| 56 | zero-cost exceptions could be implemented. |
---|
| 57 | |
---|
| 58 | Now in zero-cost exceptions the only part that is zero-cost are the try |
---|
| 59 | blocks. Some research could be done into the alternative methods for systems |
---|
| 60 | that expect a lot more exceptions to be thrown, allowing some overhead in |
---|
| 61 | entering and leaving try blocks to make throws faster. But while exceptions |
---|
| 62 | remain exceptional the libunwind model will probably remain the most effective |
---|
| 63 | option. |
---|
| 64 | |
---|
| 65 | Zero-cost resumptions have more problems to solve. First because libunwind |
---|
| 66 | does not support a successful exiting stack search without doing an unwind. |
---|
| 67 | There are several ways to hack that functionality in. Ideally an extension to |
---|
| 68 | libunwind could be made, but that would either require seperate maintenance |
---|
| 69 | or gain enough support to have it folded into the standard. |
---|
| 70 | |
---|
| 71 | Also new techniques to skip previously searched parts of the stack will have |
---|
[02b73ea] | 72 | to be developed. The recursive resume problem still remains and ideally the |
---|
| 73 | same pattern of ignoring sections of the stack. |
---|
| 74 | |
---|
| 75 | \section{Signal Exceptions} |
---|
| 76 | Exception Handling: Issues and a Proposed Notation suggests there are three |
---|
| 77 | types of exceptions: escape, notify and signal. |
---|
| 78 | Escape exceptions are our termination exceptions, notify exceptions are |
---|
| 79 | resumption exceptions and that leaves signal exception unimplemented. |
---|
| 80 | |
---|
| 81 | Signal exceptions allow either behaviour, that is after the exception is |
---|
| 82 | handled control can either return to the throw or from where the handler is |
---|
| 83 | defined. |
---|
| 84 | |
---|
| 85 | The design should be rexamined and be updated for \CFA. A very direct |
---|
| 86 | translation would perhaps have a new throw and catch pair and a statement |
---|
| 87 | (or statements) could be used to decide if the handler returns to the throw |
---|
| 88 | or continues where it is, but there are other options. |
---|
| 89 | |
---|
| 90 | For instance resumption could be extended to cover this use by allowing |
---|
| 91 | local control flow out of it. This would require an unwind as part of the |
---|
| 92 | transition as there are stack frames that have to be removed. |
---|
| 93 | This would mean there is no notify like throw but because \CFA does not have |
---|
| 94 | exception signatures a termination can be thrown from any resumption handler |
---|
| 95 | already so there are already ways one could try to do this in existing \CFA. |
---|
[a032992] | 96 | |
---|
[02b73ea] | 97 | % Maybe talk about the escape; and escape CONTROL_STMT; statements or how |
---|
| 98 | % if we could choose if _Unwind_Resume proceeded to the clean-up stage this |
---|
| 99 | % would be much easier to implement. |
---|
[a032992] | 100 | |
---|
[02b73ea] | 101 | \section{Language Improvements} |
---|
| 102 | There is also a lot of work that are not follow ups to this work in terms of |
---|
| 103 | research, some have no interesting research to be done at all, but would |
---|
| 104 | improve \CFA as a programming language. The full list of these would |
---|
| 105 | naturally be quite extensive but here are a few examples that involve |
---|
| 106 | exceptions: |
---|
[a032992] | 107 | |
---|
| 108 | \begin{itemize} |
---|
[02b73ea] | 109 | \item The implementation of termination is not portable because it includes |
---|
| 110 | some assembly statements. These sections will have to be re-written to so |
---|
| 111 | \CFA has full support on more machines. |
---|
[a032992] | 112 | \item Allowing exception handler to bind the exception to a reference instead |
---|
| 113 | of a pointer. This should actually result in no change in behaviour so there |
---|
| 114 | is no reason not to allow it. It is however a small improvement; giving a bit |
---|
| 115 | of flexibility to the user in what style they want to use. |
---|
[f28fdee] | 116 | \item Enabling local control flow (by @break@, @return@ and |
---|
[a032992] | 117 | similar statements) out of a termination handler. The current set-up makes |
---|
| 118 | this very difficult but the catch function that runs the handler after it has |
---|
| 119 | been matched could be inlined into the function's body, which would make this |
---|
| 120 | much easier. (To do the same for try blocks would probably wait for zero-cost |
---|
| 121 | exceptions, which would allow the try block to be inlined as well.) |
---|
| 122 | \end{itemize} |
---|