source: doc/theses/andrew_beach_MMath/future.tex @ edebbf7

ADTast-experimentalenumforall-pointer-decayjacob/cs343-translationnew-ast-unique-exprpthread-emulationqualifiedEnum
Last change on this file since edebbf7 was edebbf7, checked in by Andrew Beach <ajbeach@…>, 3 years ago

Andrew MMath: Folded in Peter's feedback on future. (4/6 files done.)

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