source: doc/theses/andrew_beach_MMath/future.tex @ 553f8ab

arm-ehenumforall-pointer-decayjacob/cs343-translationnew-ast-unique-expr
Last change on this file since 553f8ab was 553f8ab, checked in by Andrew Beach <ajbeach@…>, 12 months ago

Andrew MMath: Responding to Peter's suggestions on the introduction.

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