source: doc/theses/andrew_beach_MMath/future.tex @ 2f47ea4

ADTarm-ehast-experimentalenumforall-pointer-decayjacob/cs343-translationnew-ast-unique-exprpthread-emulationqualifiedEnum
Last change on this file since 2f47ea4 was 02b73ea, checked in by Andrew Beach <ajbeach@…>, 3 years ago

Andrew MMath: Added some features and cleaned up future.tex.

  • Property mode set to 100644
File size: 6.4 KB
Line 
1\chapter{Future Work}
2
3\section{Complete Virtual System}
4The virtual system should be completed. It was never supposed to be part of
5this project and so minimal work was done on it. A draft of what the complete
6system might look like was created but it was never finalized or implemented.
7A future project in \CFA would be to complete that work and to update the
8parts of the exception system that use the current version.
9
10There are several improvements to the virtual system that would improve
11the exception traits. The biggest one is an assertion that checks that one
12virtual type is a child of another virtual type. This would capture many of
13the requirements much more precisely.
14
15The full virtual system might also include other improvement like associated
16types. This is a proposed feature that would allow traits to refer to types
17not listed in their header. This would allow the exception traits to not
18refer to the virtual table type explicatly which would remove the need for
19the interface macros.
20
21\section{Additional Throws}
22Several other kinds of throws, beyond the termination throw (\codeCFA{throw}),
23the resumption throw (\codeCFA{throwResume}) and the re-throws, were considered.
24None were as useful as the core throws but they would likely be worth
25revising.
26
27The first ones are throws for asynchronous exceptions, throwing exceptions
28from one stack to another. These act like signals allowing for communication
29between the stacks. This is usually used with resumption as it allows the
30target stack to continue execution normally after the exception has been
31handled.
32
33This would much more coordination between the concurrency system and the
34exception system to handle. Most of the interesting design decisions around
35applying asynchronous exceptions appear to be around masking (controlling
36which exceptions may be thrown at a stack). It would likely require more of
37the virtual system and would also effect how default handlers are set.
38
39The other throws were designed to mimic bidirectional algebraic effects.
40Algebraic effects are used in some functional languages and allow a function
41to have another function on the stack resolve an effect (which is defined with
42a function-like interface).
43These can be mimiced with resumptions and the the new throws were designed
44to try and mimic bidirectional algebraic effects, where control can go back
45and forth between the function effect caller and handler while the effect
46is underway.
47% resume-top & resume-reply
48
49These throws would likely be just like the resumption throw except they would
50use different search patterns to find the handler to reply to.
51
52\section{Zero-Cost Exceptions}
53\CFA does not have zero-cost exceptions because it does not generate assembly
54but instead generates C code. See the implementation section. When the
55compiler does start to create its own assembly (or LLVM byte code) then
56zero-cost exceptions could be implemented.
57
58Now in zero-cost exceptions the only part that is zero-cost are the try
59blocks. Some research could be done into the alternative methods for systems
60that expect a lot more exceptions to be thrown, allowing some overhead in
61entering and leaving try blocks to make throws faster. But while exceptions
62remain exceptional the libunwind model will probably remain the most effective
63option.
64
65Zero-cost resumptions have more problems to solve. First because libunwind
66does not support a successful exiting stack search without doing an unwind.
67There are several ways to hack that functionality in. Ideally an extension to
68libunwind could be made, but that would either require seperate maintenance
69or gain enough support to have it folded into the standard.
70
71Also new techniques to skip previously searched parts of the stack will have
72to be developed. The recursive resume problem still remains and ideally the
73same pattern of ignoring sections of the stack.
74
75\section{Signal Exceptions}
76Exception Handling: Issues and a Proposed Notation suggests there are three
77types of exceptions: escape, notify and signal.
78Escape exceptions are our termination exceptions, notify exceptions are
79resumption exceptions and that leaves signal exception unimplemented.
80
81Signal exceptions allow either behaviour, that is after the exception is
82handled control can either return to the throw or from where the handler is
83defined.
84
85The design should be rexamined and be updated for \CFA. A very direct
86translation would perhaps have a new throw and catch pair and a statement
87(or statements) could be used to decide if the handler returns to the throw
88or continues where it is, but there are other options.
89
90For instance resumption could be extended to cover this use by allowing
91local control flow out of it. This would require an unwind as part of the
92transition as there are stack frames that have to be removed.
93This would mean there is no notify like throw but because \CFA does not have
94exception signatures a termination can be thrown from any resumption handler
95already so there are already ways one could try to do this in existing \CFA.
96
97% Maybe talk about the escape; and escape CONTROL_STMT; statements or how
98% if we could choose if _Unwind_Resume proceeded to the clean-up stage this
99% would be much easier to implement.
100
101\section{Language Improvements}
102There is also a lot of work that are not follow ups to this work in terms of
103research, some have no interesting research to be done at all, but would
104improve \CFA as a programming language. The full list of these would
105naturally be quite extensive but here are a few examples that involve
106exceptions:
107
108\begin{itemize}
109\item The implementation of termination is not portable because it includes
110some assembly statements. These sections will have to be re-written to so
111\CFA has full support on more machines.
112\item Allowing exception handler to bind the exception to a reference instead
113of a pointer. This should actually result in no change in behaviour so there
114is no reason not to allow it. It is however a small improvement; giving a bit
115of flexibility to the user in what style they want to use.
116\item Enabling local control flow (by \codeCFA{break}, \codeCFA{return} and
117similar statements) out of a termination handler. The current set-up makes
118this very difficult but the catch function that runs the handler after it has
119been matched could be inlined into the function's body, which would make this
120much easier. (To do the same for try blocks would probably wait for zero-cost
121exceptions, which would allow the try block to be inlined as well.)
122\end{itemize}
Note: See TracBrowser for help on using the repository browser.