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

For instance a full virtual system would probably allow for several
improvements to the exception traits. Although they do currently work they
could be made easier to use by making the virtual table type implitate in the
trait (which would remove the need for those wrapper marcos) or allowing
for assertions that give the layout of a virtual table for safety.

\section{Additional Throws}
Several other kinds of throws, beyond the termination throw (\codeCFA{throw}),
the resumption throw (\codeCFA{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.

\section{Support for More Platforms}
Termination is not portable because it is implemented with inline assembly.
Those sections will have to be rewritten to support different architectures

\section{Quality-of-Life Improvements}
Finally come various improvements to the usability of \CFA. Most of these
would just require time. Time that would not lead to interesting research so
it has been left aside for now. A few examples are included here but there
are more:

\begin{itemize}
\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 \codeCFA{break}, \codeCFA{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.)
\item Enabling local control flow out of a resumption handler. This would be
a weighty operation, causing a stack unwind like a termination, so there might
be a different statement or a statement modifier to make sure the user does
this purposefully.

However this would require the more complex system as they cannot be inlined
into the original function as they can be run at a different place on the
stack. So instead the unwinding will have to carry with it information on
which one of these points to continue at and possibly also the return value
for the function if a \codeCFA{return} statement was used.
\end{itemize}