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

enumforall-pointer-decayjacob/cs343-translationnew-ast-unique-expr
Last change on this file since b6749fd was b6749fd, checked in by Peter A. Buhr <pabuhr@…>, 11 months ago

proofread Andrew's implement, performance and future chapters

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