source: doc/theses/andrew_beach_MMath/future.tex @ 7eb6eb5

arm-ehjacob/cs343-translationnew-ast-unique-expr
Last change on this file since 7eb6eb5 was 7eb6eb5, checked in by Peter A. Buhr <pabuhr@…>, 9 months ago

complete first proofread of Andrew's thesis

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