source: doc/theses/andrew_beach_MMath/future.tex @ 7620e5d

Last change on this file since 7620e5d was 7620e5d, checked in by Peter A. Buhr <pabuhr@…>, 3 years ago

proofread future chapter

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