source: doc/theses/andrew_beach_MMath/future.tex@ 1f8f5a7

\chapter{Future Work}

\section{Complete Virtual System}
The virtual system should be completed. It was never supposed to be part of
this project and so minimal work was done on it. A draft of what the complete
system might look like was created but it was never finalized or implemented.
A future project in \CFA would be to complete that work and to update the
parts of the exception system that use the current version.

There are several improvements to the virtual system that would improve
the exception traits. The biggest one is an assertion that checks that one
virtual type is a child of another virtual type. This would capture many of
the requirements much more precisely.

The full virtual system might also include other improvement like associated
types. This is a proposed feature that would allow traits to refer to types
not listed in their header. This would allow the exception traits to not
refer to the virtual table type explicatly which would remove the need for
the interface macros.

\section{Additional Throws}
Several other kinds of throws, beyond the termination throw (@throw@),
the resumption throw (@throwResume@) and the re-throws, were considered.
None were as useful as the core throws but they would likely be worth
revising.

The first ones are throws for asynchronous exceptions, throwing exceptions
from one stack to another. These act like signals allowing for communication
between the stacks. This is usually used with resumption as it allows the
target stack to continue execution normally after the exception has been
handled.

This would much more coordination between the concurrency system and the
exception system to handle. Most of the interesting design decisions around
applying asynchronous exceptions appear to be around masking (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.

The other throws were designed to mimic bidirectional algebraic effects.
Algebraic effects are used in some functional languages and allow a function
to have another function on the stack resolve an effect (which is defined with
a function-like interface).
These can be mimiced with resumptions and the the new throws were designed
to try and 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 throws would likely be just like the resumption throw except they would
use different search patterns to find the handler to reply to.

\section{Zero-Cost Exceptions}
\CFA does not have zero-cost exceptions because it does not generate assembly
but instead generates C code. See the implementation section. When the
compiler does start to create its own assembly (or LLVM byte code) then
zero-cost exceptions could be implemented.

Now in zero-cost exceptions the only part that is zero-cost are the try
blocks. Some research could be done into the alternative methods for systems
that expect a lot more exceptions to be thrown, allowing some overhead in
entering and leaving try blocks to make throws faster. But while exceptions
remain exceptional the libunwind model will probably remain the most effective
option.

Zero-cost resumptions have more problems to solve. First because libunwind
does not support a successful exiting stack search without doing an unwind.
There are several ways to hack that functionality in. Ideally an extension to
libunwind could be made, but that would either require seperate maintenance
or gain enough support to have it folded into the standard.

Also new techniques to skip previously searched parts of the stack will have
to be developed. The recursive resume problem still remains and ideally the
same pattern of ignoring sections of the stack.

\section{Signal Exceptions}
Exception Handling: Issues and a Proposed Notation suggests there are three
types of exceptions: escape, notify and signal.
Escape exceptions are our termination exceptions, notify exceptions are
resumption exceptions and that leaves signal exception unimplemented.

Signal exceptions allow either behaviour, that is after the exception is
handled control can either return to the throw or from where the handler is
defined.

The design should be rexamined and be updated for \CFA. A very direct
translation would perhaps have a new throw and catch pair and a statement
(or statements) could be used to decide if the handler returns to the throw
or continues where it is, but there are other options.

For instance resumption could be extended to cover this use by allowing
local control flow out of it. This would require an unwind as part of the
transition as there are stack frames that have to be removed.
This would mean there is no notify like throw but because \CFA does not have
exception signatures a termination can be thrown from any resumption handler
already so there are already ways one could try to do this in existing \CFA.

% 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.

\section{Language Improvements}
There is also a lot of work that are not follow ups to this work in terms of
research, some have no interesting research to be done at all, but would
improve \CFA as a programming language. The full list of these would
naturally be quite extensive but here are a few examples that involve
exceptions:

\begin{itemize}
\item The implementation of termination is not portable because it includes
some assembly statements. These sections will have to be re-written to so
\CFA has full support on more machines.
\item Allowing exception handler to bind the exception to a reference instead
of a pointer. This should actually result in no change in behaviour so there
is no reason not to allow it. It is however a small improvement; giving a bit
of flexibility to the user in what style they want to use.
\item Enabling local control flow (by @break@, @return@ and
similar statements) out of a termination handler. The current set-up makes
this very difficult but the catch function that runs the handler after it has
been matched could be inlined into the function's body, which would make this
much easier. (To do the same for try blocks would probably wait for zero-cost
exceptions, which would allow the try block to be inlined as well.)
\end{itemize}