Changeset 7eb6eb5 for doc/theses/andrew_beach_MMath/future.tex

Timestamp:

Jan 29, 2021, 8:23:52 AM (4 years ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum

Children:

5669d0b

Parents:

4dcd5ea

Message:

complete first proofread of Andrew's thesis

File:

• doc/theses/andrew_beach_MMath/future.tex (modified) (1 diff)

doc/theses/andrew_beach_MMath/future.tex

@@ -1 +1 @@
 \chapter{Future Work}
 
+\section{Language Improvements}
+\CFA is a developing programming language. As such, there are partially or
+unimplemented features of the language (including several broken components)
+that I had to workaround while building an exception handling system largely in
+the \CFA language (some C components).  The following are a few of these
+issues, and once implemented/fixed, how this would affect the exception system.
+\begin{itemize}
+\item
+The implementation of termination is not portable because it includes
+hand-crafted assembly statements. These sections must be generalized to support
+more hardware architectures, \eg ARM processor.
+\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.
+\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 assemble-code generation at the
+@try@ statement). Hence, when the handler runs, its code is not in the lexical
+scope of the @try@ statement, where the local control-flow transfers are
+meaningful.
+\end{itemize}
+
 \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.
+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 was done. A draft for a complete virtual system is available but
+it is 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 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.
+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
+correctness requirements.
 
 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.
+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.
 
-\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.
+\section{Additional Raises}
+Several other kinds of exception raises were considered beyond termination
+(@throw@), resumption (@throwResume@), and reraise.
 
-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.
+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.
 
-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.
+Non-local/concurrent requires more coordination between the concurrency system
+and the exception system. Many of the interesting design decisions centre
+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
+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 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.
+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.
 
-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 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.
 
-\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.
+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.
 
-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 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 gain enough
+support to have it folded into the standard.
 
-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.
+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}
-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.
+Goodenough~\cite{Goodenough75} suggests three types of exceptions: escape,
+notify and signal.  Escape are termination exceptions, notify are resumption
+exceptions, leaving signal 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.
+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.
 
-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.
+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 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.
+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.  This approach
+means there is no notify raise, but because \CFA does not have exception
+signatures, a termination can be thrown from within any resumption handler so
+there is already a way to do mimic 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}