# Changeset edebbf7

Ignore:
Timestamp:
Jun 16, 2021, 11:50:15 AM (7 months ago)
Branches:
jacob/cs343-translation, master, new-ast-unique-expr
Children:
029cbc0
Parents:
6071efc
Message:

Andrew MMath: Folded in Peter's feedback on future. (4/6 files done.)

File:
1 edited

### Legend:

Unmodified
 r6071efc \section{Language Improvements} \todo{Future/Language Improvements seems to have gotten mixed up. It is presented as waiting on language improvements" but really its more non-research based impovements.} \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. issues, and once implemented/fixed, how they 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 ported by hand to hand-crafted assembly statements. The existing compilers cannot translate that for other platforms and those sections must be ported by hand to support more hardware architectures, such as the ARM processor. \item 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. result in little or no change in the exception system but simplify usage. \item Termination handlers cannot use local control-flow transfers, \eg by @break@, 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 minimal work is 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. bad software engineering. Non-local/concurrent requires more coordination between the concurrency system Non-local/concurrent raise 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 around masking, \ie 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. \section{Checked Exceptions} Checked exceptions make exceptions part of a function's type by adding the Checked exceptions make exceptions part of a function's type by adding an exception signature. An exception signature must declare all checked exceptions that could propogate from the function (either because they were exceptions that could propagate from the function (either because they were raised inside the function or came from a sub-function). This improves safety by making sure every checked exception is either handled or consciously However checked exceptions were never seriously considered for this project for two reasons. The first is due to time constraints, even copying an existing checked exception system would be pushing the remaining time and trying to address the second problem would take even longer. The second problem is that checked exceptions have some real usability trade-offs in because they have significant trade-offs in usablity and code reuse in exchange for the increased safety. These trade-offs are most problematic when trying to pass exceptions through higher-order functions from the functions the user passed into the higher-order function. There are no well known solutions to this problem that were statifactory for \CFA (which carries some of C's flexability over safety design) so one would have to be researched and developed. that were satisfactory for \CFA (which carries some of C's flexibility over safety design) so additional research is needed. Follow-up work might add checked exceptions to \CFA, possibly using polymorphic exception signatures, a form of tunneling\cite{Zhang19} or Follow-up work might add some form of checked exceptions to \CFA, possibly using polymorphic exception signatures, a form of tunneling\cite{Zhang19} or checked and unchecked raises. 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. transition as there are stack frames that have to be removed between where the resumption handler is installed and where it is defined. This approach would not require, but might benefit from, a special statement to leave the handler. Currently, mimicking this behaviour in \CFA is possible by throwing a termination inside a resumption handler. % Maybe talk about the escape; and escape CONTROL_STMT; statements or how