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

arm-ehjacob/cs343-translationnew-ast-unique-expr
Last change on this file since 1dfe6a6 was a032992, checked in by Andrew Beach <ajbeach@…>, 11 months ago

Made a symbol compatable with hyperref and added first version of the future work chapter.

  • Property mode set to 100644
File size: 5.3 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
10For instance a full virtual system would probably allow for several
11improvements to the exception traits. Although they do currently work they
12could be made easier to use by making the virtual table type implitate in the
13trait (which would remove the need for those wrapper marcos) or allowing
14for assertions that give the layout of a virtual table for safety.
15
16\section{Additional Throws}
17Several other kinds of throws, beyond the termination throw (\codeCFA{throw}),
18the resumption throw (\codeCFA{throwResume}) and the re-throws, were considered.
19None were as useful as the core throws but they would likely be worth
20revising.
21
22The first ones are throws for asynchronous exceptions, throwing exceptions
23from one stack to another. These act like signals allowing for communication
24between the stacks. This is usually used with resumption as it allows the
25target stack to continue execution normally after the exception has been
26handled.
27
28This would much more coordination between the concurrency system and the
29exception system to handle. Most of the interesting design decisions around
30applying asynchronous exceptions appear to be around masking (controlling
31which exceptions may be thrown at a stack). It would likely require more of
32the virtual system and would also effect how default handlers are set.
33
34The other throws were designed to mimic bidirectional algebraic effects.
35Algebraic effects are used in some functional languages and allow a function
36to have another function on the stack resolve an effect (which is defined with
37a function-like interface).
38These can be mimiced with resumptions and the the new throws were designed
39to try and mimic bidirectional algebraic effects, where control can go back
40and forth between the function effect caller and handler while the effect
41is underway.
42% resume-top & resume-reply
43
44These throws would likely be just like the resumption throw except they would
45use different search patterns to find the handler to reply to.
46
47\section{Zero-Cost Exceptions}
48\CFA does not have zero-cost exceptions because it does not generate assembly
49but instead generates C code. See the implementation section. When the
50compiler does start to create its own assembly (or LLVM byte code) then
51zero-cost exceptions could be implemented.
52
53Now in zero-cost exceptions the only part that is zero-cost are the try
54blocks. Some research could be done into the alternative methods for systems
55that expect a lot more exceptions to be thrown, allowing some overhead in
56entering and leaving try blocks to make throws faster. But while exceptions
57remain exceptional the libunwind model will probably remain the most effective
58option.
59
60Zero-cost resumptions have more problems to solve. First because libunwind
61does not support a successful exiting stack search without doing an unwind.
62There are several ways to hack that functionality in. Ideally an extension to
63libunwind could be made, but that would either require seperate maintenance
64or gain enough support to have it folded into the standard.
65
66Also new techniques to skip previously searched parts of the stack will have
67to be developed.
68
69\section{Support for More Platforms}
70Termination is not portable because it is implemented with inline assembly.
71Those sections will have to be rewritten to support different architectures
72
73\section{Quality-of-Life Improvements}
74Finally come various improvements to the usability of \CFA. Most of these
75would just require time. Time that would not lead to interesting research so
76it has been left aside for now. A few examples are included here but there
77are more:
78
79\begin{itemize}
80\item Allowing exception handler to bind the exception to a reference instead
81of a pointer. This should actually result in no change in behaviour so there
82is no reason not to allow it. It is however a small improvement; giving a bit
83of flexibility to the user in what style they want to use.
84\item Enabling local control flow (by \codeCFA{break}, \codeCFA{return} and
85similar statements) out of a termination handler. The current set-up makes
86this very difficult but the catch function that runs the handler after it has
87been matched could be inlined into the function's body, which would make this
88much easier. (To do the same for try blocks would probably wait for zero-cost
89exceptions, which would allow the try block to be inlined as well.)
90\item Enabling local control flow out of a resumption handler. This would be
91a weighty operation, causing a stack unwind like a termination, so there might
92be a different statement or a statement modifier to make sure the user does
93this purposefully.
94
95However this would require the more complex system as they cannot be inlined
96into the original function as they can be run at a different place on the
97stack. So instead the unwinding will have to carry with it information on
98which one of these points to continue at and possibly also the return value
99for the function if a \codeCFA{return} statement was used.
100\end{itemize}
Note: See TracBrowser for help on using the repository browser.