Changeset 9cd37d9


Ignore:
Timestamp:
Aug 23, 2021, 1:58:44 PM (5 months ago)
Author:
Andrew Beach <ajbeach@…>
Branches:
jacob/cs343-translation, master
Children:
ba2e8f0
Parents:
c2a9d88
Message:

Andrew MMath: Folded in Peter's feedback on the Future Work chapter.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/andrew_beach_MMath/future.tex

    rc2a9d88 r9cd37d9  
    22\label{c:future}
    33
     4The following discussion covers both possible interesting research
     5that could follow from this work as long as simple implementation
     6improvements.
     7
    48\section{Language Improvements}
    5 \todo{Future/Language Improvements seems to have gotten mixed up. It is
    6 presented as ``waiting on language improvements" but really its more
    7 non-research based impovements.}
     9
    810\CFA is a developing programming language. As such, there are partially or
    9 unimplemented features of the language (including several broken components)
    10 that I had to workaround while building an exception handling system largely in
    11 the \CFA language (some C components).  The following are a few of these
    12 issues, and once implemented/fixed, how they would affect the exception system.
     11unimplemented features (including several broken components)
     12that I had to workaround while building the EHM largely in
     13the \CFA language (some C components). Below are a few of these issues
     14and how implementing/fixing them would affect the EHM.
     15In addition there are some simple improvements that had no interesting
     16research attached to them but would make using the language easier.
    1317\begin{itemize}
    14 \item
    15 The implementation of termination is not portable because it includes
    16 hand-crafted assembly statements.
    17 The existing compilers cannot translate that for other platforms and those
    18 sections must be ported by hand to
    19 support more hardware architectures, such as the ARM processor.
    2018\item
    2119Due to a type-system problem, the catch clause cannot bind the exception to a
     
    2725@return@, \etc. The reason is that current code generation hoists a handler
    2826into a nested function for convenience (versus assemble-code generation at the
    29 @try@ statement). Hence, when the handler runs, its code is not in the lexical
    30 scope of the @try@ statement, where the local control-flow transfers are
    31 meaningful.
     27try statement). Hence, when the handler runs, it can still access local
     28variables in the lexical scope of the try statement. Still, it does mean
     29that seemingly local control flow is not in fact local and crosses a function
     30boundary.
     31Making the termination handlers code within the surrounding
     32function would remove this limitation.
     33% Try blocks are much more difficult to do practically (requires our own
     34% assembly) and resumption handlers have some theoretical complexity.
    3235\item
    3336There is no detection of colliding unwinds. It is possible for clean-up code
    3437run during an unwind to trigger another unwind that escapes the clean-up code
    3538itself; such as a termination exception caught further down the stack or a
    36 cancellation. There do exist ways to handle this but currently they are not
    37 even detected and the first unwind will simply be forgotten, often leaving
     39cancellation. There do exist ways to handle this case, but currently there is
     40no detection and the first unwind will simply be forgotten, often leaving
    3841it in a bad state.
    3942\item
    40 Also the exception system did not have a lot of time to be tried and tested.
    41 So just letting people use the exception system more will reveal new
    42 quality of life upgrades that can be made with time.
     43Finally, the exception system has not had a lot of programmer testing.
     44More time with encouraged usage will reveal new
     45quality of life upgrades that can be made.
    4346\end{itemize}
    4447
     
    4750project, but was thrust upon it to do exception inheritance; hence, only
    4851minimal work is done. A draft for a complete virtual system is available but
    49 it is not finalized. A future \CFA project is to complete that work and then
     52not finalized. A future \CFA project is to complete that work and then
    5053update the exception system that uses the current version.
    5154
     
    5356exception traits. The most important one is an assertion to check one virtual
    5457type is a child of another. This check precisely captures many of the
    55 correctness requirements.
     58current ad-hoc correctness requirements.
    5659
    5760The full virtual system might also include other improvement like associated
    5861types to allow traits to refer to types not listed in their header. This
    5962feature allows exception traits to not refer to the virtual-table type
    60 explicitly, removing the need for the current interface macros.
     63explicitly, removing the need for the current interface macros,
     64such as @EHM_IS_EXCEPTION@.
    6165
    6266\section{Additional Raises}
     
    7478Non-local/concurrent raise requires more
    7579coordination between the concurrency system
    76 and the exception system. Many of the interesting design decisions centre
     80and the exception system. Many of the interesting design decisions center
    7781around masking, \ie controlling which exceptions may be thrown at a stack. It
    7882would likely require more of the virtual system and would also effect how
     
    9397Checked exceptions make exceptions part of a function's type by adding an
    9498exception signature. An exception signature must declare all checked
    95 exceptions that could propagate from the function (either because they were
    96 raised inside the function or came from a sub-function). This improves safety
     99exceptions that could propagate from the function, either because they were
     100raised inside the function or came from a sub-function. This improves safety
    97101by making sure every checked exception is either handled or consciously
    98102passed on.
    99103
    100104However checked exceptions were never seriously considered for this project
    101 because they have significant trade-offs in usablity and code reuse in
     105because they have significant trade-offs in usability and code reuse in
    102106exchange for the increased safety.
    103107These trade-offs are most problematic when trying to pass exceptions through
     
    129133not support a successful-exiting stack-search without doing an unwind.
    130134Workarounds are possible but awkward. Ideally an extension to libunwind could
    131 be made, but that would either require separate maintenance or gain enough
    132 support to have it folded into the standard.
     135be made, but that would either require separate maintenance or gaining enough
     136support to have it folded into the official library itself.
    133137
    134138Also new techniques to skip previously searched parts of the stack need to be
     
    158162to leave the handler.
    159163Currently, mimicking this behaviour in \CFA is possible by throwing a
    160 termination inside a resumption handler.
     164termination exception inside a resumption handler.
    161165
    162166% Maybe talk about the escape; and escape CONTROL_STMT; statements or how
Note: See TracChangeset for help on using the changeset viewer.