Changeset edebbf7

Jun 16, 2021, 11:50:15 AM (7 months ago)
Andrew Beach <ajbeach@…>
jacob/cs343-translation, master, new-ast-unique-expr

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

1 edited


  • doc/theses/andrew_beach_MMath/future.tex

    r6071efc redebbf7  
    44\section{Language Improvements}
     5\todo{Future/Language Improvements seems to have gotten mixed up. It is
     6presented as ``waiting on language improvements" but really its more
     7non-research based impovements.}
    58\CFA is a developing programming language. As such, there are partially or
    69unimplemented features of the language (including several broken components)
    710that I had to workaround while building an exception handling system largely in
    811the \CFA language (some C components).  The following are a few of these
    9 issues, and once implemented/fixed, how this would affect the exception system.
     12issues, and once implemented/fixed, how they would affect the exception system.
    1215The implementation of termination is not portable because it includes
    13 hand-crafted assembly statements. These sections must be ported by hand to
     16hand-crafted assembly statements.
     17The existing compilers cannot translate that for other platforms and those
     18sections must be ported by hand to
    1419support more hardware architectures, such as the ARM processor.
    1722reference instead of a pointer. Since \CFA has a very general reference
    1823capability, programmers will want to use it. Once fixed, this capability should
    19 result in little or no change in the exception system.
     24result in little or no change in the exception system but simplify usage.
    2126Termination handlers cannot use local control-flow transfers, \eg by @break@,
    4146The virtual system should be completed. It was not supposed to be part of this
    4247project, but was thrust upon it to do exception inheritance; hence, only
    43 minimal work was done. A draft for a complete virtual system is available but
     48minimal work is done. A draft for a complete virtual system is available but
    4449it is not finalized.  A future \CFA project is to complete that work and then
    4550update the exception system that uses the current version.
    6772bad software engineering.
    69 Non-local/concurrent requires more coordination between the concurrency system
     74Non-local/concurrent raise requires more
     75coordination between the concurrency system
    7076and the exception system. Many of the interesting design decisions centre
    71 around masking (controlling which exceptions may be thrown at a stack). It
     77around masking, \ie controlling which exceptions may be thrown at a stack. It
    7278would likely require more of the virtual system and would also effect how
    7379default handlers are set.
    8692\section{Checked Exceptions}
    87 Checked exceptions make exceptions part of a function's type by adding the
     93Checked exceptions make exceptions part of a function's type by adding an
    8894exception signature. An exception signature must declare all checked
    89 exceptions that could propogate from the function (either because they were
     95exceptions that could propagate from the function (either because they were
    9096raised inside the function or came from a sub-function). This improves safety
    9197by making sure every checked exception is either handled or consciously
    94100However checked exceptions were never seriously considered for this project
    95 for two reasons. The first is due to time constraints, even copying an
    96 existing checked exception system would be pushing the remaining time and
    97 trying to address the second problem would take even longer. The second
    98 problem is that checked exceptions have some real usability trade-offs in
     101because they have significant trade-offs in usablity and code reuse in
    99102exchange for the increased safety.
    101103These trade-offs are most problematic when trying to pass exceptions through
    102104higher-order functions from the functions the user passed into the
    103105higher-order function. There are no well known solutions to this problem
    104 that were statifactory for \CFA (which carries some of C's flexability
    105 over safety design) so one would have to be researched and developed.
     106that were satisfactory for \CFA (which carries some of C's flexibility
     107over safety design) so additional research is needed.
    107 Follow-up work might add checked exceptions to \CFA, possibly using
    108 polymorphic exception signatures, a form of tunneling\cite{Zhang19} or
     109Follow-up work might add some form of checked exceptions to \CFA,
     110possibly using polymorphic exception signatures,
     111a form of tunneling\cite{Zhang19} or
    109112checked and unchecked raises.
    150153For instance, resumption could be extended to cover this use by allowing local
    151154control flow out of it. This approach would require an unwind as part of the
    152 transition as there are stack frames that have to be removed.  This approach
    153 means there is no notify raise, but because \CFA does not have exception
    154 signatures, a termination can be thrown from within any resumption handler so
    155 there is already a way to do mimic this in existing \CFA.
     155transition as there are stack frames that have to be removed between where
     156the resumption handler is installed and where it is defined.
     157This approach would not require, but might benefit from, a special statement
     158to leave the handler.
     159Currently, mimicking this behaviour in \CFA is possible by throwing a
     160termination inside a resumption handler.
    157162% Maybe talk about the escape; and escape CONTROL_STMT; statements or how
Note: See TracChangeset for help on using the changeset viewer.