source: doc/theses/andrew_beach_MMath/future.tex @ 221c542e

\chapter{Future Work}
\label{c:future}

The following discussion covers both possible interesting research
that could follow from this work as well as simple implementation
improvements.

\section{Language Improvements}

\CFA is a developing programming language. As such, there are partially or
unimplemented features (including several broken components)
that I had to work around while building the EHM largely in
the \CFA language (some C components). Below are a few of these issues
and how implementing/fixing them would affect the EHM.
In addition, there are some simple improvements that had no interesting
research attached to them but would make using the language easier.
\begin{itemize}
\item
Due to a type-system problem, the catch clause cannot bind the exception to a
reference instead of a pointer. Since \CFA has a very general reference
capability, programmers will want to use it. Once fixed, this capability should
result in little or no change in the exception system but simplify usage.
\item
The @copy@ function in the exception virtual table is an adapter to address
some limitations in the \CFA copy constructor. If the copy constructor is
improved it can be used directly without the adapter.
\item
Termination handlers cannot use local control-flow transfers, \eg by @break@,
@return@, \etc. The reason is that current code generation hoists a handler
into a nested function for convenience (versus assembly-code generation at the
try statement). Hence, when the handler runs, it can still access local
variables in the lexical scope of the try statement. Still, it does mean
that seemingly local control flow is not in fact local and crosses a function
boundary.
Making the termination handler's code within the surrounding
function would remove this limitation.
% Try blocks are much more difficult to do practically (requires our own
% assembly) and resumption handlers have some theoretical complexity.
\item
There is no detection of colliding unwinds. It is possible for cleanup code
run during an unwind to trigger another unwind that escapes the cleanup code
itself, such as a termination exception caught further down the stack or a
cancellation. There do exist ways to handle this case, but currently there is
no detection and the first unwind will simply be forgotten, often leaving
it in a bad state.
\item
Finally, the exception system has not had a lot of programmer testing.
More time with encouraged usage will reveal new
quality of life upgrades that can be made.
\end{itemize}

\section{Complete Virtual System}
The virtual system should be completed. It was not supposed to be part of this
project, but was thrust upon it to do exception inheritance; hence, only
minimal work is done. A draft for a complete virtual system is available but
not finalized. A future \CFA project is to complete that work and then
update the exception system that uses the current version.

There are several improvements to the virtual system that would improve the
exception traits. The most important one is an assertion to check one virtual
type is a child of another. This check precisely captures many of the
current ad-hoc correctness requirements.

Other features of the virtual system could also remove some of the
special cases around exception virtual tables, such as the generation
of the @msg@ function.

The full virtual system might also include other improvement like associated
types to allow traits to refer to types not listed in their header. This
feature allows exception traits to not refer to the virtual-table type
explicitly, removing the need for the current interface macros,
such as @EHM_IS_EXCEPTION@.

\section{Additional Raises}
Several other kinds of exception raises were considered beyond termination
(@throw@), resumption (@throwResume@), and re-raise.

The first is a non-local/concurrent raise providing asynchronous exceptions,
\ie raising an exception on another stack. This semantics acts like signals
allowing for out-of-band communication among coroutines and threads. This kind
of raise is often restricted to resumption to allow the target stack to
continue execution normally after the exception has been handled. That is,
allowing one coroutine/thread to unwind the stack of another via termination is
bad software engineering.

Non-local/concurrent raise requires more
coordination between the concurrency system
and the exception system. Many of the interesting design decisions center
around masking, \ie controlling which exceptions may be thrown at a stack. It
would likely require more of the virtual system and would also effect how
default handlers are set.

Other raises were considered to mimic bidirectional algebraic effects.
Algebraic effects are used in some functional languages allowing one function
to have another function on the stack resolve an effect (which is defined with
a functional-like interface).  This semantics can be mimicked with resumptions
and new raises were discussed to mimic bidirectional algebraic-effects, where
control can go back and forth between the function-effect caller and handler
while the effect is underway.
% resume-top & resume-reply
These raises would be like the resumption raise except using different search
patterns to find the handler.

\section{Checked Exceptions}
Checked exceptions make exceptions part of a function's type by adding an
exception signature. An exception signature must declare all checked
exceptions that could propagate from the function, either because they were
raised inside the function or came from a sub-function. This improves safety
by making sure every checked exception is either handled or consciously
passed on.

Checked exceptions were never seriously considered for this project
because they have significant trade-offs in usability and code reuse in
exchange for the increased safety.
These trade-offs are most problematic when trying to pass exceptions through
higher-order functions from the functions the user passed into the
higher-order function. There are no well known solutions to this problem
that were satisfactory for \CFA (which carries some of C's
flexibility-over-safety design) so additional research is needed.

Follow-up work might add some form of checked exceptions to \CFA,
possibly using polymorphic exception signatures,
a form of tunneling\cite{Zhang19} or
checked and unchecked raises.

\section{Zero-Cost Try}
\CFA does not have zero-cost try-statements because the compiler generates C
code rather than assembler code (see \vpageref{p:zero-cost}). When the compiler
does create its own assembly (or LLVM byte-code), then zero-cost try-statements
are possible. The downside of zero-cost try-statements is the LSDA complexity,
its size (program bloat), and the high cost of raising an exception.

Alternatively, some research could be done into the simpler alternative method
with a non-zero-cost try-statement but much lower cost exception raise. For
example, programs are starting to use exception in the normal control path, so
more exceptions are thrown. In these cases, the cost balance switches towards
low-cost raise. Unfortunately, while exceptions remain exceptional, the
libunwind model will probably remain the most effective option.

Zero-cost resumptions is still an open problem. First, because libunwind does
not support a successful-exiting stack-search without doing an unwind.
Workarounds are possible but awkward. Ideally, an extension to libunwind could
be made, but that would either require separate maintenance or gaining enough
support to have it folded into the official library itself.

Also, new techniques to skip previously searched parts of the stack need to be
developed to handle the recursive resume problem and support advanced algebraic
effects.

\section{Signal Exceptions}
Goodenough~\cite{Goodenough75} suggests three types of exceptions: escape,
notify and signal.  Escape are termination exceptions, notify are resumption
exceptions, leaving signal unimplemented.

A signal exception allows either behaviour, \ie after an exception is handled,
the handler has the option of returning to the raise or after the @try@
statement. Currently, \CFA fixes the semantics of the handler return
syntactically by the @catch@ or @catchResume@ clause.

Signal exception should be reexamined and possibly be supported in \CFA. A very
direct translation is to have a new raise and catch pair, and a new statement
(or statements) would indicate if the handler returns to the raise or continues
where it is; but there may be other options.

For instance, resumption could be extended to cover this use by allowing local
control flow out of it. This approach would require an unwind as part of the
transition as there are stack frames that have to be removed between where
the resumption handler is installed and where it is defined.
This approach would not require, but might benefit from, a special statement
to leave the handler.
Currently, mimicking this behaviour in \CFA is possible by throwing a
termination exception inside a resumption handler.

% Maybe talk about the escape; and escape CONTROL_STMT; statements or how
% if we could choose if _Unwind_Resume proceeded to the clean-up stage this
% would be much easier to implement.