- Timestamp:
- Jun 16, 2021, 11:50:15 AM (3 years ago)
- Branches:
- ADT, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum
- Children:
- 029cbc0
- Parents:
- 6071efc
- File:
-
- 1 edited
-
doc/theses/andrew_beach_MMath/future.tex (modified) (7 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/andrew_beach_MMath/future.tex
r6071efc redebbf7 3 3 4 4 \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.} 5 8 \CFA is a developing programming language. As such, there are partially or 6 9 unimplemented features of the language (including several broken components) 7 10 that I had to workaround while building an exception handling system largely in 8 11 the \CFA language (some C components). The following are a few of these 9 issues, and once implemented/fixed, how th iswould affect the exception system.12 issues, and once implemented/fixed, how they would affect the exception system. 10 13 \begin{itemize} 11 14 \item 12 15 The implementation of termination is not portable because it includes 13 hand-crafted assembly statements. These sections must be ported by hand to 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 14 19 support more hardware architectures, such as the ARM processor. 15 20 \item … … 17 22 reference instead of a pointer. Since \CFA has a very general reference 18 23 capability, programmers will want to use it. Once fixed, this capability should 19 result in little or no change in the exception system .24 result in little or no change in the exception system but simplify usage. 20 25 \item 21 26 Termination handlers cannot use local control-flow transfers, \eg by @break@, … … 41 46 The virtual system should be completed. It was not supposed to be part of this 42 47 project, 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 but48 minimal work is done. A draft for a complete virtual system is available but 44 49 it is not finalized. A future \CFA project is to complete that work and then 45 50 update the exception system that uses the current version. … … 67 72 bad software engineering. 68 73 69 Non-local/concurrent requires more coordination between the concurrency system 74 Non-local/concurrent raise requires more 75 coordination between the concurrency system 70 76 and the exception system. Many of the interesting design decisions centre 71 around masking (controlling which exceptions may be thrown at a stack). It77 around masking, \ie controlling which exceptions may be thrown at a stack. It 72 78 would likely require more of the virtual system and would also effect how 73 79 default handlers are set. … … 85 91 86 92 \section{Checked Exceptions} 87 Checked exceptions make exceptions part of a function's type by adding the93 Checked exceptions make exceptions part of a function's type by adding an 88 94 exception signature. An exception signature must declare all checked 89 exceptions that could prop ogate from the function (either because they were95 exceptions that could propagate from the function (either because they were 90 96 raised inside the function or came from a sub-function). This improves safety 91 97 by making sure every checked exception is either handled or consciously … … 93 99 94 100 However 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 101 because they have significant trade-offs in usablity and code reuse in 99 102 exchange for the increased safety. 100 101 103 These trade-offs are most problematic when trying to pass exceptions through 102 104 higher-order functions from the functions the user passed into the 103 105 higher-order function. There are no well known solutions to this problem 104 that were s tatifactory for \CFA (which carries some of C's flexability105 over safety design) so one would have to be researched and developed.106 that were satisfactory for \CFA (which carries some of C's flexibility 107 over safety design) so additional research is needed. 106 108 107 Follow-up work might add checked exceptions to \CFA, possibly using 108 polymorphic exception signatures, a form of tunneling\cite{Zhang19} or 109 Follow-up work might add some form of checked exceptions to \CFA, 110 possibly using polymorphic exception signatures, 111 a form of tunneling\cite{Zhang19} or 109 112 checked and unchecked raises. 110 113 … … 150 153 For instance, resumption could be extended to cover this use by allowing local 151 154 control 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. 155 transition as there are stack frames that have to be removed between where 156 the resumption handler is installed and where it is defined. 157 This approach would not require, but might benefit from, a special statement 158 to leave the handler. 159 Currently, mimicking this behaviour in \CFA is possible by throwing a 160 termination inside a resumption handler. 156 161 157 162 % Maybe talk about the escape; and escape CONTROL_STMT; statements or how
Note: See TracChangeset
for help on using the changeset viewer.
