Changeset 21f2e92
- Timestamp:
- Jun 7, 2021, 4:00:16 PM (4 years ago)
- Branches:
- ADT, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum
- Children:
- 382edbe
- Parents:
- dac16a0
- Location:
- doc/theses/andrew_beach_MMath
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/andrew_beach_MMath/existing.tex
rdac16a0 r21f2e92 2 2 \label{c:existing} 3 3 4 \CFA is an open-source project extending ISO C with4 \CFA (C-for-all)~\cite{Cforall} is an open-source project extending ISO C with 5 5 modern safety and productivity features, while still ensuring backwards 6 6 compatibility with C and its programmers. \CFA is designed to have an … … 9 9 existing C code-base allowing programmers to learn \CFA on an as-needed basis. 10 10 11 Only those \CFA features pert ainingto this thesis are discussed. Many of the11 Only those \CFA features pertinent to this thesis are discussed. Many of the 12 12 \CFA syntactic and semantic features used in the thesis should be fairly 13 13 obvious to the reader. … … 29 29 // name mangling on by default 30 30 int i; // _X1ii_1 31 @extern "C"@{ // disables name mangling31 extern "C" { // disables name mangling 32 32 int j; // j 33 @extern "Cforall"@{ // enables name mangling33 extern "Cforall" { // enables name mangling 34 34 int k; // _X1ki_1 35 35 } … … 45 45 \CFA adds a reference type to C as an auto-dereferencing pointer. 46 46 They work very similarly to pointers. 47 Reference-types are written the same way as a pointer-type but each47 Reference-types are written the same way as a pointer-type is but each 48 48 asterisk (@*@) is replaced with a ampersand (@&@); 49 this includes cv-qualifiers and multiple levels of reference, \eg: 50 51 \begin{minipage}{0,5\textwidth} 49 this includes cv-qualifiers and multiple levels of reference. 50 51 They are intended for cases where you would want to use pointers but would 52 be dereferencing them (almost) every usage. 53 In most cases a reference can just be thought of as a pointer that 54 automatically puts a dereference infront of each of its uses (per-level of 55 reference). 56 The address-of operator (@&@) acts as an escape and removes one of the 57 automatic dereference operations. 58 Mutable references may be assigned to by converting them to a pointer 59 with a @&@ and then assigning a pointer too them. 60 61 \begin{minipage}{0,45\textwidth} 52 62 With references: 53 63 \begin{cfa} … … 56 66 int && rri = ri; 57 67 rri = 3; 58 &ri = &j; // reference assignment68 &ri = &j; 59 69 ri = 5; 60 70 \end{cfa} 61 71 \end{minipage} 62 \begin{minipage}{0, 5\textwidth}72 \begin{minipage}{0,45\textwidth} 63 73 With pointers: 64 74 \begin{cfa} … … 67 77 int ** ppi = π 68 78 **ppi = 3; 69 pi = &j; // pointer assignment79 pi = &j; 70 80 *pi = 5; 71 81 \end{cfa} 72 82 \end{minipage} 73 83 74 References are intended for cases where you would want to use pointers but would 75 be dereferencing them (almost) every usage. 76 In most cases a reference can just be thought of as a pointer that 77 automatically puts a dereference in front of each of its uses (per-level of 78 reference). 79 The address-of operator (@&@) acts as an escape and removes one of the 80 automatic dereference operations. 81 Mutable references may be assigned by converting them to a pointer 82 with a @&@ and then assigning a pointer to them, as in @&ri = &j;@ above. 83 84 \section{Operators} 84 \section{Constructors and Destructors} 85 86 Both constructors and destructors are operators, which means they are 87 functions with special operator names rather than type names in \Cpp. The 88 special operator names may be used to call the functions explicitly (not 89 allowed in \Cpp for constructors). 85 90 86 91 In general, operator names in \CFA are constructed by bracketing an operator … … 90 95 (such as @++?@) and post-fix operations (@?++@). 91 96 92 An operator name may describe any function signature (it is just a name) but 93 only certain signatures may be called in operator form. 94 \begin{cfa} 95 int ?+?( int i, int j, int k ) { return i + j + k; } 97 The special name for a constructor is @?{}@, which comes from the 98 initialization syntax in C. That initialation syntax is also the operator 99 form. \CFA will generate a constructor call each time a variable is declared, 100 passing the initialization arguments to the constructort. 101 \begin{cfa} 102 struct Example { ... }; 103 void ?{}(Example & this) { ... } 96 104 { 97 sout | ?+?( 3, 4, 5 ); // no infix form 98 } 99 \end{cfa} 100 Some ``near-misses" for unary/binary operator prototypes generate warnings. 101 102 Both constructors and destructors are operators, which means they are 103 functions with special operator names rather than type names in \Cpp. The 104 special operator names may be used to call the functions explicitly (not 105 allowed in \Cpp for constructors). 106 107 The special name for a constructor is @?{}@, where the name @{}@ comes from the 108 initialization syntax in C, \eg @Structure s = {...}@. 109 % That initialization syntax is also the operator form. 110 \CFA generates a constructor call each time a variable is declared, 111 passing the initialization arguments to the constructor. 112 \begin{cfa} 113 struct Structure { ... }; 114 void ?{}(Structure & this) { ... } 105 Example a; 106 Example b = {}; 107 } 108 void ?{}(Example & this, char first, int num) { ... } 115 109 { 116 Structure a; 117 Structure b = {}; 118 } 119 void ?{}(Structure & this, char first, int num) { ... } 110 Example c = {'a', 2}; 111 } 112 \end{cfa} 113 Both @a@ and @b@ will be initalized with the first constructor (there is no 114 general way to skip initialation) while @c@ will be initalized with the 115 second. 116 117 % I don't like the \^{} symbol but $^\wedge$ isn't better. 118 Similarly destructors use the special name @^?{}@ (the @^@ has no special 119 meaning). They can be called explicatly as well but normally they are 120 implicitly called on a variable when it goes out of scope. 121 \begin{cfa} 122 void ^?{}(Example & this) { ... } 120 123 { 121 Structure c = {'a', 2}; 122 } 123 \end{cfa} 124 Both @a@ and @b@ are initialized with the first constructor, 125 while @c@ is initialized with the second. 126 Currently, there is no general way to skip initialization. 127 128 % I don't like the \^{} symbol but $^\wedge$ isn't better. 129 Similarly, destructors use the special name @^?{}@ (the @^@ has no special 130 meaning). Normally, they are implicitly called on a variable when it goes out 131 of scope but they can be called explicitly as well. 132 \begin{cfa} 133 void ^?{}(Structure & this) { ... } 134 { 135 Structure d; 124 Example d; 136 125 } // <- implicit destructor call 137 126 \end{cfa} 138 139 Whenever a type is defined, \CFA creates a default zero-argument 127 No operator name is restricted in what function signatures they may be bound 128 to although most of the forms cannot be called in operator form. Some 129 ``near-misses" will generate warnings. 130 131 Whenever a type is defined, \CFA will create a default zero-argument 140 132 constructor, a copy constructor, a series of argument-per-field constructors 141 133 and a destructor. All user constructors are defined after this. … … 161 153 char capital_a = identity( 'A' ); 162 154 \end{cfa} 163 Each use of a polymorphic declaration resolvesits polymorphic parameters155 Each use of a polymorphic declaration will resolve its polymorphic parameters 164 156 (in this case, just @T@) to concrete types (@int@ in the first use and @char@ 165 157 in the second). … … 167 159 To allow a polymorphic function to be separately compiled, the type @T@ must be 168 160 constrained by the operations used on @T@ in the function body. The @forall@ 169 clause is augmented with a list of polymorphic variables (local type names)161 clauses is augmented with a list of polymorphic variables (local type names) 170 162 and assertions (constraints), which represent the required operations on those 171 163 types used in a function, \eg: 172 164 \begin{cfa} 173 forall( T | { void do_once(T); } 165 forall( T | { void do_once(T); }) 174 166 void do_twice(T value) { 175 167 do_once(value); … … 198 190 void do_once(double y) { ... } 199 191 int quadruple(int x) { 200 void do_once(int y) { y = y * 2; } // replace global do_once 201 do_twice(x); // use local do_once 202 do_twice(x + 1.5); // use global do_once 192 void do_once(int y) { y = y * 2; } 193 do_twice(x); 203 194 return x; 204 195 } 205 196 \end{cfa} 206 197 Specifically, the complier deduces that @do_twice@'s T is an integer from the 207 argument @x@. It then looks for the most \emph{specific}definition matching the198 argument @x@. It then looks for the most specific definition matching the 208 199 assertion, which is the nested integral @do_once@ defined within the 209 200 function. The matched assertion function is then passed as a function pointer 210 to @do_twice@ and called within it. The global definition of @do_once@ is used211 for the second call because the float-point argument is a better match.201 to @do_twice@ and called within it. 202 The global definition of @do_once@ is ignored. 212 203 213 204 To avoid typing long lists of assertions, constraints can be collect into … … 279 270 Each coroutine has a @main@ function, which takes a reference to a coroutine 280 271 object and returns @void@. 281 \begin{cfa} [numbers=left]272 \begin{cfa} 282 273 void main(CountUp & this) { 283 274 for (unsigned int next = 0 ; true ; ++next) { 284 275 next = up; 285 276 suspend;$\label{suspend}$ -
doc/theses/andrew_beach_MMath/features.tex
rdac16a0 r21f2e92 3 3 4 4 This chapter covers the design and user interface of the \CFA 5 EHM, % or exception system. 6 and begins with a general overview of EHMs. It is not a strict 7 definition of all EHMs nor an exhaustive list of all possible features. 8 However it does cover the most common structures and features found in them. 5 exception-handling mechanism (EHM). % or exception system. 6 7 We will begin with an overview of EHMs in general. It is not a strict 8 definition of all EHMs nor an exaustive list of all possible features. 9 However it does cover the most common structure and features found in them. 9 10 10 11 % We should cover what is an exception handling mechanism and what is an 11 12 % exception before this. Probably in the introduction. Some of this could 12 13 % move there. 13 \ section{Raise / Handle}14 \paragraph{Raise / Handle} 14 15 An exception operation has two main parts: raise and handle. 15 16 These terms are sometimes also known as throw and catch but this work uses 16 17 throw/catch as a particular kind of raise/handle. 17 These are the two parts that the user w rites and may18 These are the two parts that the user will write themselves and may 18 19 be the only two pieces of the EHM that have any syntax in the language. 19 20 20 \ paragraph{Raise}21 \subparagraph{Raise} 21 22 The raise is the starting point for exception handling. It marks the beginning 22 of exception handling by raising an excep tion, which passes it to23 of exception handling by raising an excepion, which passes it to 23 24 the EHM. 24 25 25 26 Some well known examples include the @throw@ statements of \Cpp and Java and 26 the \code{Python}{raise} statement from Python. Araise may27 p erform some other work (such as memory management) but for the27 the \code{Python}{raise} statement from Python. In real systems a raise may 28 preform some other work (such as memory management) but for the 28 29 purposes of this overview that can be ignored. 29 30 30 \ paragraph{Handle}31 \subparagraph{Handle} 31 32 The purpose of most exception operations is to run some user code to handle 32 33 that exception. This code is given, with some other information, in a handler. 33 34 34 35 A handler has three common features: the previously mentioned user code, a 35 region of code they guard,and an exception label/condition that matches36 region of code they cover and an exception label/condition that matches 36 37 certain exceptions. 37 Only raises inside the guarded region and raising exceptions that match the38 Only raises inside the covered region and raising exceptions that match the 38 39 label can be handled by a given handler. 39 Different EHMs have different rules to pick a handler,40 if multip le handlers could be used,such as ``best match" or ``first found".40 Different EHMs will have different rules to pick a handler 41 if multipe handlers could be used such as ``best match" or ``first found". 41 42 42 43 The @try@ statements of \Cpp, Java and Python are common examples. All three 43 also show another common feature of handlers, they are grouped by the guarded44 also show another common feature of handlers, they are grouped by the covered 44 45 region. 45 46 46 \ section{Propagation}47 \paragraph{Propagation} 47 48 After an exception is raised comes what is usually the biggest step for the 48 EHM: finding and setting up the handler. The prop agation from raise to49 EHM: finding and setting up the handler. The propogation from raise to 49 50 handler can be broken up into three different tasks: searching for a handler, 50 matching against the handler ,and installing the handler.51 52 \ paragraph{Searching}51 matching against the handler and installing the handler. 52 53 \subparagraph{Searching} 53 54 The EHM begins by searching for handlers that might be used to handle 54 55 the exception. Searching is usually independent of the exception that was 55 thrown as it looks for handlers that have the raise site in their guarded56 thrown as it looks for handlers that have the raise site in their covered 56 57 region. 57 This searchincludes handlers in the current function, as well as any in callers58 on the stack that have the function call in their guarded region.59 60 \ paragraph{Matching}58 This includes handlers in the current function, as well as any in callers 59 on the stack that have the function call in their covered region. 60 61 \subparagraph{Matching} 61 62 Each handler found has to be matched with the raised exception. The exception 62 label defines a condition that is used with the exception to decideif63 label defines a condition that be use used with exception and decides if 63 64 there is a match or not. 64 65 65 In languages where the first match is used ,this step is intertwined with66 searching : a match check is performed immediately after the search finds66 In languages where the first match is used this step is intertwined with 67 searching, a match check is preformed immediately after the search finds 67 68 a possible handler. 68 69 69 \s ection{Installing}70 \subparagraph{Installing} 70 71 After a handler is chosen it must be made ready to run. 71 72 The implementation can vary widely to fit with the rest of the … … 74 75 case when stack unwinding is involved. 75 76 76 If a matching handler is not guarantied to be found, the EHM needs a 77 different course of action for the case where no handler matches. 78 This situation only occurs with unchecked exceptions as checked exceptions 79 (such as in Java) can make the guarantee. 80 This unhandled action can abort the program or install a very general handler. 81 82 \paragraph{Hierarchy} 77 If a matching handler is not guarantied to be found the EHM will need a 78 different course of action here in the cases where no handler matches. 79 This is only required with unchecked exceptions as checked exceptions 80 (such as in Java) can make than guaranty. 81 This different action can also be installing a handler but it is usually an 82 implicat and much more general one. 83 84 \subparagraph{Hierarchy} 83 85 A common way to organize exceptions is in a hierarchical structure. 84 This organization is often usedin object-orientated languages where the86 This is especially true in object-orientated languages where the 85 87 exception hierarchy is a natural extension of the object hierarchy. 86 88 … … 111 113 112 114 The EHM can return control to many different places, 113 the most common are after the handler definition (termination) and after the raise (resumption).115 the most common are after the handler definition and after the raise. 114 116 115 117 \paragraph{Communication} 116 118 For effective exception handling, additional information is often passed 117 from the raise to the handler and back again.119 from the raise to the handler. 118 120 So far only communication of the exceptions' identity has been covered. 119 A common communicationmethod is putting fields into the exception instance and giving the120 handler access to them. References in the exception instance can push data back to the raise.121 A common method is putting fields into the exception instance and giving the 122 handler access to them. 121 123 122 124 \section{Virtuals} 123 125 Virtual types and casts are not part of \CFA's EHM nor are they required for 124 126 any EHM. 125 However , one of the best ways to support an exception hierarchy is via a virtual system126 among exceptions and used forexception matching.127 128 Ideally, the virtual system would havebeen part of \CFA before the work127 However the \CFA uses a hierarchy built with the virtual system as the basis 128 for exceptions and exception matching. 129 130 The virtual system would have ideally been part of \CFA before the work 129 131 on exception handling began, but unfortunately it was not. 130 Therefore,only the features and framework needed for the EHM were132 Because of this only the features and framework needed for the EHM were 131 133 designed and implemented. Other features were considered to ensure that 132 the structure could accom modate other desirable features in the futurebut they were not134 the structure could accomidate other desirable features but they were not 133 135 implemented. 134 The rest of this section discusses the implemented subsetof the135 virtual -system design.136 The rest of this section will only discuss the finalized portion of the 137 virtual system. 136 138 137 139 The virtual system supports multiple ``trees" of types. Each tree is … … 143 145 % A type's ancestors are its parent and its parent's ancestors. 144 146 % The root type has no ancestors. 145 % A type's dece dents are its children and its children's decedents.147 % A type's decendents are its children and its children's decendents. 146 148 147 149 Every virtual type also has a list of virtual members. Children inherit … … 149 151 It is important to note that these are virtual members, not virtual methods 150 152 of object-orientated programming, and can be of any type. 151 152 \PAB{I do not understand these sentences. Can you add an example? $\Rightarrow$153 153 \CFA still supports virtual methods as a special case of virtual members. 154 Function pointers that take a pointer to the virtual type are modified154 Function pointers that take a pointer to the virtual type will be modified 155 155 with each level of inheritance so that refers to the new type. 156 156 This means an object can always be passed to a function in its virtual table 157 as if it were a method. }157 as if it were a method. 158 158 159 159 Each virtual type has a unique id. 160 This id and all the virtual members are combined160 This unique id and all the virtual members are combined 161 161 into a virtual table type. Each virtual type has a pointer to a virtual table 162 162 as a hidden field. 163 164 \PAB{God forbid, maybe you need a UML diagram to relate these entities.}165 163 166 164 Up until this point the virtual system is similar to ones found in 167 165 object-orientated languages but this where \CFA diverges. Objects encapsulate a 168 166 single set of behaviours in each type, universally across the entire program, 169 and indeed all programs that use that type definition. In this sense ,the167 and indeed all programs that use that type definition. In this sense the 170 168 types are ``closed" and cannot be altered. 171 169 172 In \CFA ,types do not encapsulate any behaviour. Traits are local and173 types can begin to s atisfy a trait, stop satisfying a trait or satisfy the same170 In \CFA types do not encapsulate any behaviour. Traits are local and 171 types can begin to statify a trait, stop satifying a trait or satify the same 174 172 trait in a different way at any lexical location in the program. 175 In this sense , they are ``open" as they can change at any time. This capabilitymeans it176 is imp ossible to pick a single set of functions that represent the type's173 In this sense they are ``open" as they can change at any time. This means it 174 is implossible to pick a single set of functions that repersent the type's 177 175 implementation across the program. 178 176 179 177 \CFA side-steps this issue by not having a single virtual table for each 180 type. A user can define virtual tables thatare filled in at their181 declaration and given a name. Anywhere that name is visible, even if 182 defined locally inside a function (although that means it doesnot have a178 type. A user can define virtual tables which are filled in at their 179 declaration and given a name. Anywhere that name is visible, even if it was 180 defined locally inside a function (although that means it will not have a 183 181 static lifetime), it can be used. 184 Specifically, a virtual type is ``bound" to a virtual table that182 Specifically, a virtual type is ``bound" to a virtual table which 185 183 sets the virtual members for that object. The virtual members can be accessed 186 184 through the object. 187 185 188 \PAB{The above explanation is very good!}189 190 186 While much of the virtual infrastructure is created, it is currently only used 191 187 internally for exception handling. The only user-level feature is the virtual 192 cast 188 cast, which is the same as the \Cpp \code{C++}{dynamic_cast}. 193 189 \label{p:VirtualCast} 194 190 \begin{cfa} 195 191 (virtual TYPE)EXPRESSION 196 192 \end{cfa} 197 which is the same as the \Cpp \code{C++}{dynamic_cast}.198 193 Note, the syntax and semantics matches a C-cast, rather than the function-like 199 194 \Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be … … 217 212 \end{cfa} 218 213 The trait is defined over two types, the exception type and the virtual table 219 type. Each exception type should have a single virtual table type.220 There are no actual assertions in this trait because currentlythe trait system221 cannot express them (adding such assertions would be part of214 type. Each exception type should have but a single virtual table type. 215 Now there are no actual assertions in this trait because the trait system 216 actually can't express them (adding such assertions would be part of 222 217 completing the virtual system). The imaginary assertions would probably come 223 218 from a trait defined by the virtual system, and state that the exception type 224 is a virtual type, is a de scendent of @exception_t@ (the base exception type)219 is a virtual type, is a decendent of @exception_t@ (the base exception type) 225 220 and note its virtual table type. 226 221 … … 241 236 }; 242 237 \end{cfa} 243 Both traits ensure a pair of types are an exception type and its virtual table ,238 Both traits ensure a pair of types are an exception type and its virtual table 244 239 and defines one of the two default handlers. The default handlers are used 245 240 as fallbacks and are discussed in detail in \vref{s:ExceptionHandling}. … … 269 264 \section{Exception Handling} 270 265 \label{s:ExceptionHandling} 271 As stated,\CFA provides two kinds of exception handling: termination and resumption.266 \CFA provides two kinds of exception handling: termination and resumption. 272 267 These twin operations are the core of \CFA's exception handling mechanism. 273 This section coversthe general patterns shared by the two operations and274 then go on to cover the details ofeach individual operation.268 This section will cover the general patterns shared by the two operations and 269 then go on to cover the details each individual operation. 275 270 276 271 Both operations follow the same set of steps. 277 Both start with the user p erforming a raise on an exception.278 Then the exception prop agates up the stack.272 Both start with the user preforming a raise on an exception. 273 Then the exception propogates up the stack. 279 274 If a handler is found the exception is caught and the handler is run. 280 After that control returns to a point specific to the kind of exception.281 If the search fails a default handler is run , and if it returns,control282 continues after the raise. Note, the default handler may further change control flow rather than return.275 After that control returns to normal execution. 276 If the search fails a default handler is run and then control 277 returns to normal execution after the raise. 283 278 284 279 This general description covers what the two kinds have in common. 285 Differences include how prop agation is performed, where exception continues280 Differences include how propogation is preformed, where exception continues 286 281 after an exception is caught and handled and which default handler is run. 287 282 288 283 \subsection{Termination} 289 284 \label{s:Termination} 290 291 285 Termination handling is the familiar kind and used in most programming 292 286 languages with exception handling. 293 It is adynamic, non-local goto. If the raised exception is matched and294 handled , the stack is unwound and control (usually) continues inthe function287 It is dynamic, non-local goto. If the raised exception is matched and 288 handled the stack is unwound and control will (usually) continue the function 295 289 on the call stack that defined the handler. 296 290 Termination is commonly used when an error has occurred and recovery is … … 307 301 termination exception is any type that satisfies the trait 308 302 @is_termination_exception@ at the call site. 309 Through \CFA's trait system , the trait functions are implicitly passed into the303 Through \CFA's trait system the trait functions are implicity passed into the 310 304 throw code and the EHM. 311 305 A new @defaultTerminationHandler@ can be defined in any scope to 312 change the throw's behavio ur (see below).313 314 The throw copiesthe provided exception into managed memory to ensure315 the exception is not destroyed whenthe stack is unwound.306 change the throw's behavior (see below). 307 308 The throw will copy the provided exception into managed memory to ensure 309 the exception is not destroyed if the stack is unwound. 316 310 It is the user's responsibility to ensure the original exception is cleaned 317 up whe ther the stack is unwound or not. Allocating it on the stack is311 up wheither the stack is unwound or not. Allocating it on the stack is 318 312 usually sufficient. 319 313 320 Then prop agation startsthe search. \CFA uses a ``first match" rule so321 matching is p erformed with the copied exception as the search continues.322 It starts from the throwing function and proceeds to wardsthe base of the stack,314 Then propogation starts with the search. \CFA uses a ``first match" rule so 315 matching is preformed with the copied exception as the search continues. 316 It starts from the throwing function and proceeds to the base of the stack, 323 317 from callee to caller. 324 318 At each stack frame, a check is made for resumption handlers defined by the … … 333 327 } 334 328 \end{cfa} 335 When viewed on its own, a try statement simply executesthe statements336 in \snake{GUARDED_BLOCK} and when those are finished ,the try statement finishes.329 When viewed on its own, a try statement will simply execute the statements 330 in \snake{GUARDED_BLOCK} and when those are finished the try statement finishes. 337 331 338 332 However, while the guarded statements are being executed, including any 339 invoked functions, all the handlers in the se statements are includedon the search340 path. Hence, if a termination exception is raised, the search includes the added handlers associated with the guarded block and thosefurther up the341 stack from the guarded block.333 invoked functions, all the handlers in the statement are now on the search 334 path. If a termination exception is thrown and not handled further up the 335 stack they will be matched against the exception. 342 336 343 337 Exception matching checks the handler in each catch clause in the order 344 they appear, top to bottom. If the representation of the raisedexception type338 they appear, top to bottom. If the representation of the thrown exception type 345 339 is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$ 346 (if provided) is bound to a pointer to the exception and the statements in347 @HANDLER_BLOCK@$_i$ are executed. 348 If control reaches the end of the handler, the exception is340 (if provided) is 341 bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$ 342 are executed. If control reaches the end of the handler, the exception is 349 343 freed and control continues after the try statement. 350 344 351 If no termination handler is found during the search ,the default handler352 (\defaultTerminationHandler) visible at the raise statement is called.353 Through \CFA's trait system , the best match at the raise sight isused.354 This function is run and is passed the copied exception. Ifthe default355 handler returns,control continues after the throw statement.345 If no termination handler is found during the search then the default handler 346 (\defaultTerminationHandler) is run. 347 Through \CFA's trait system the best match at the throw sight will be used. 348 This function is run and is passed the copied exception. After the default 349 handler is run control continues after the throw statement. 356 350 357 351 There is a global @defaultTerminationHandler@ that is polymorphic over all 358 termination exception types. Since it is so general,a more specific handler can be359 defined and isused for those types, effectively overriding the handler360 for aparticular exception type.352 exception types. Since it is so general a more specific handler can be 353 defined and will be used for those types, effectively overriding the handler 354 for particular exception type. 361 355 The global default termination handler performs a cancellation 362 356 (see \vref{s:Cancellation}) on the current stack with the copied exception. … … 368 362 just as old~\cite{Goodenough75} and is simpler in many ways. 369 363 It is a dynamic, non-local function call. If the raised exception is 370 matched a closure is taken from up the stack and executed, 371 after which the raising function continues executing. 372 These are most often used when a potentially repairable error occurs, some handler is found on the stack to fix it, and 373 the raising function can continue with the correction. 374 Another common usage is dynamic event analysis, \eg logging, without disrupting control flow. 375 Note, if an event is raised and there is no interest, control continues normally. 376 377 \PAB{We also have \lstinline{report} instead of \lstinline{throwResume}, \lstinline{recover} instead of \lstinline{catch}, and \lstinline{fixup} instead of \lstinline{catchResume}. 378 You may or may not want to mention it. You can still stick with \lstinline{catch} and \lstinline{throw/catchResume} in the thesis.} 364 matched a closure will be taken from up the stack and executed, 365 after which the raising function will continue executing. 366 These are most often used when an error occurred and if the error is repaired 367 then the function can continue. 379 368 380 369 A resumption raise is started with the @throwResume@ statement: … … 387 376 @is_resumption_exception@ at the call site. 388 377 The assertions from this trait are available to 389 the exception system ,while handling the exception.390 391 Resumption does not need to copy the raised exception, as the stack is not unwound.392 The exception and393 any values on the stack remain in scope,while the resumption is handled.378 the exception system while handling the exception. 379 380 At run-time, no exception copy is made. 381 As the stack is not unwound the exception and 382 any values on the stack will remain in scope while the resumption is handled. 394 383 395 384 The EHM then begins propogation. The search starts from the raise in the 396 resuming function and proceeds to wardsthe base of the stack, from callee to caller.385 resuming function and proceeds to the base of the stack, from callee to caller. 397 386 At each stack frame, a check is made for resumption handlers defined by the 398 387 @catchResume@ clauses of a @try@ statement. … … 409 398 Note that termination handlers and resumption handlers may be used together 410 399 in a single try statement, intermixing @catch@ and @catchResume@ freely. 411 Each type of handler only interactswith exceptions from the matching412 kindof raise.413 When a try statement is executed ,it simply executes the statements in the414 @GUARDED_BLOCK@ and then returns.400 Each type of handler will only interact with exceptions from the matching 401 type of raise. 402 When a try statement is executed it simply executes the statements in the 403 @GUARDED_BLOCK@ and then finishes. 415 404 416 405 However, while the guarded statements are being executed, including any 417 invoked functions, all the handlers in the se statements are includedon the search418 path. Hence, if a resumption exception is raised the search includes the added handlers associated with the guarded block and thosefurther up the419 stack from the guarded block.406 invoked functions, all the handlers in the statement are now on the search 407 path. If a resumption exception is reported and not handled further up the 408 stack they will be matched against the exception. 420 409 421 410 Exception matching checks the handler in each catch clause in the order 422 they appear, top to bottom. If the representation of the raisedexception type411 they appear, top to bottom. If the representation of the thrown exception type 423 412 is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$ 424 413 (if provided) is bound to a pointer to the exception and the statements in … … 427 416 the raise statement that raised the handled exception. 428 417 429 Like termination, if no resumption handler is found during the search, the default handler 430 (\defaultResumptionHandler) visible at the raise statement is called. 431 It uses the best match at the 432 raise sight according to \CFA's overloading rules. The default handler is 418 Like termination, if no resumption handler is found, the default handler 419 visible at the throw statement is called. It will use the best match at the 420 call sight according to \CFA's overloading rules. The default handler is 433 421 passed the exception given to the throw. When the default handler finishes 434 422 execution continues after the raise statement. 435 423 436 There is a global \defaultResumptionHandler{} that is polymorphic over all 437 resumption exception types and preforms a termination throw on the exception. 438 The \defaultTerminationHandler{} can be 424 There is a global \defaultResumptionHandler{} is polymorphic over all 425 termination exceptions and preforms a termination throw on the exception. 426 The \defaultTerminationHandler{} for that raise is matched at the 427 original raise statement (the resumption @throw@\-@Resume@) and it can be 439 428 customized by introducing a new or better match as well. 440 429 441 430 \subsubsection{Resumption Marking} 442 431 \label{s:ResumptionMarking} 443 444 432 A key difference between resumption and termination is that resumption does 445 433 not unwind the stack. A side effect that is that when a handler is matched 446 and run , its try block (the guarded statements) and every try statement447 searched before it are still on the stack. Th eir existencecan lead to the recursive434 and run it's try block (the guarded statements) and every try statement 435 searched before it are still on the stack. This can lead to the recursive 448 436 resumption problem. 449 437 … … 458 446 } 459 447 \end{cfa} 460 When this code is executed , the guarded @throwResume@ startsa461 search and match s the handler in the @catchResume@ clause. This462 call is placed on the top of stack above the try-block. The second throw463 searchs the same try block and putscall another instance of the464 same handler on the stack leading to an infinite recursion.465 466 While this situation is trivial and easy to avoid,much more complex cycles448 When this code is executed the guarded @throwResume@ will throw, start a 449 search and match the handler in the @catchResume@ clause. This will be 450 call and placed on the stack on top of the try-block. The second throw then 451 throws and will search the same try block and put call another instance of the 452 same handler leading to an infinite loop. 453 454 This situation is trivial and easy to avoid, but much more complex cycles 467 455 can form with multiple handlers and different exception types. 468 456 469 To prevent all of these cases , the exception search marks the try statements it visits.457 To prevent all of these cases we mark try statements on the stack. 470 458 A try statement is marked when a match check is preformed with it and an 471 exception. The statement isunmarked when the handling of that exception459 exception. The statement will be unmarked when the handling of that exception 472 460 is completed or the search completes without finding a handler. 473 While a try statement is marked ,its handlers are never matched, effectify474 skipping over themto the next try statement.461 While a try statement is marked its handlers are never matched, effectify 462 skipping over it to the next try statement. 475 463 476 464 \begin{center} … … 479 467 480 468 These rules mirror what happens with termination. 481 When a termination throw happens in a handler , the search doesnot look at469 When a termination throw happens in a handler the search will not look at 482 470 any handlers from the original throw to the original catch because that 483 part of the stack isunwound.471 part of the stack has been unwound. 484 472 A resumption raise in the same situation wants to search the entire stack, 485 but with marking, the search does match exceptions for try statements at equivalent sections486 that would have been unwound by termination.487 488 The symmetry between resumption termination is why this pattern is picked.489 Other patterns, such as marking just the handlers that caught the exception, also work but490 lack the symmetry , meaningthere are more rules to remember.473 but it will not try to match the exception with try statements in the section 474 that would have been unwound as they are marked. 475 476 The symmetry between resumption termination is why this pattern was picked. 477 Other patterns, such as marking just the handlers that caught, also work but 478 lack the symmetry means there are more rules to remember. 491 479 492 480 \section{Conditional Catch} 493 494 481 Both termination and resumption handler clauses can be given an additional 495 482 condition to further control which exceptions they handle: … … 504 491 did not match. 505 492 506 The condition matching allows finer matching to check493 The condition matching allows finer matching by allowing the match to check 507 494 more kinds of information than just the exception type. 508 495 \begin{cfa} … … 519 506 // Can't handle a failure relating to f2 here. 520 507 \end{cfa} 521 In this example ,the file that experianced the IO error is used to decide508 In this example the file that experianced the IO error is used to decide 522 509 which handler should be run, if any at all. 523 510 … … 548 535 549 536 \subsection{Comparison with Reraising} 550 551 537 A more popular way to allow handlers to match in more detail is to reraise 552 the exception after it has been caught ,if it could not be handled here.538 the exception after it has been caught if it could not be handled here. 553 539 On the surface these two features seem interchangable. 554 540 555 If @throw@ is usedto start a termination reraise then these two statements556 have the same behaviour:541 If we used @throw;@ to start a termination reraise then these two statements 542 would have the same behaviour: 557 543 \begin{cfa} 558 544 try { … … 574 560 } 575 561 \end{cfa} 576 However, if there are further handlers after this handler only the first is 577 check. For multiple handlers on a single try block that could handle the 578 same exception, the equivalent translations to conditional catch becomes more complex, resulting is multiple nested try blocks for all possible reraises. 579 So while catch-with-reraise is logically equivilant to conditional catch, there is a lexical explosion for the former. 580 581 \PAB{I think the following discussion makes an incorrect assumption. 582 A conditional catch CAN happen with the stack unwound. 583 Roy talked about this issue in Section 2.3.3 here: \newline 584 \url{http://plg.uwaterloo.ca/theses/KrischerThesis.pdf}} 585 586 Specifically for termination handling, a 562 If there are further handlers after this handler only the first version will 563 check them. If multiple handlers on a single try block that could handle the 564 same exception the translations get more complex but they are equivilantly 565 powerful. 566 567 Until stack unwinding comes into the picture. In termination handling, a 587 568 conditional catch happens before the stack is unwound, but a reraise happens 588 569 afterwards. Normally this might only cause you to loose some debug 589 570 information you could get from a stack trace (and that can be side stepped 590 571 entirely by collecting information during the unwind). But for \CFA there is 591 another issue, if the exception is not handled the default handler should be572 another issue, if the exception isn't handled the default handler should be 592 573 run at the site of the original raise. 593 574 594 There are two problems with this: the site of the original raise does not595 exist anymore and the default handler might not exist anymore. The site is596 always removed as part of the unwinding, often with the entirety of the575 There are two problems with this: the site of the original raise doesn't 576 exist anymore and the default handler might not exist anymore. The site will 577 always be removed as part of the unwinding, often with the entirety of the 597 578 function it was in. The default handler could be a stack allocated nested 598 579 function removed during the unwind. … … 605 586 \section{Finally Clauses} 606 587 \label{s:FinallyClauses} 607 608 588 Finally clauses are used to preform unconditional clean-up when leaving a 609 589 scope and are placed at the end of a try statement after any handler clauses: … … 618 598 The @FINALLY_BLOCK@ is executed when the try statement is removed from the 619 599 stack, including when the @GUARDED_BLOCK@ finishes, any termination handler 620 finishes ,or during an unwind.600 finishes or during an unwind. 621 601 The only time the block is not executed is if the program is exited before 622 602 the stack is unwound. … … 634 614 635 615 Not all languages with unwinding have finally clauses. Notably \Cpp does 636 without it as des tructors with RAIIserve a similar role. Although destructors and637 finally clauses have overlapping usage cases,they have their own638 specializations,like top-level functions and lambda functions with closures.639 Destructors take more work if a number of unrelated, local variables without destructors or dynamically allocated variables must be passed for de-intialization.640 Maintaining this destructor during local-block modification is a source of errors. 641 A finally clause places local de-intialization inline with direct access to all local variables.616 without it as descructors serve a similar role. Although destructors and 617 finally clauses can be used in many of the same areas they have their own 618 use cases like top-level functions and lambda functions with closures. 619 Destructors take a bit more work to set up but are much easier to reuse while 620 finally clauses are good for one-off uses and 621 can easily include local information. 642 622 643 623 \section{Cancellation} … … 652 632 raise, this exception is not used in matching only to pass information about 653 633 the cause of the cancellation. 654 (This restrictionalso means matching cannot fail so there is no default handler.)634 (This also means matching cannot fail so there is no default handler.) 655 635 656 636 After @cancel_stack@ is called the exception is copied into the EHM's memory 657 637 and the current stack is 658 unwound. 659 The result of a cancellation depends on the kind of stack that is being unwound. 638 unwound. After that it depends one which stack is being cancelled. 660 639 661 640 \paragraph{Main Stack} … … 664 643 After the main stack is unwound there is a program-level abort. 665 644 666 There are two reasons for this semantics. The first is that it obviously had to do the abort645 There are two reasons for this. The first is that it obviously had to do this 667 646 in a sequential program as there is nothing else to notify and the simplicity 668 647 of keeping the same behaviour in sequential and concurrent programs is good. 669 \PAB{I do not understand this sentence. $\Rightarrow$ Also, even in concurrent programs,there is no stack that an innate connection670 to, so it would have be explicitly managed. }648 Also, even in concurrent programs there is no stack that an innate connection 649 to, so it would have be explicitly managed. 671 650 672 651 \paragraph{Thread Stack} 673 652 A thread stack is created for a \CFA @thread@ object or object that satisfies 674 653 the @is_thread@ trait. 675 After a thread stack is unwound , the exception is stored until another654 After a thread stack is unwound there exception is stored until another 676 655 thread attempts to join with it. Then the exception @ThreadCancelled@, 677 656 which stores a reference to the thread and to the exception passed to the 678 cancellation, is reported from the join to the joining thread.657 cancellation, is reported from the join. 679 658 There is one difference between an explicit join (with the @join@ function) 680 659 and an implicit join (from a destructor call). The explicit join takes the 681 660 default handler (@defaultResumptionHandler@) from its calling context while 682 the implicit join provides its own ,which does a program abort if the661 the implicit join provides its own which does a program abort if the 683 662 @ThreadCancelled@ exception cannot be handled. 684 663 685 \PAB{Communication can occur during the lifetime of a thread using shared variable and \lstinline{waitfor} statements. 686 Are you sure you mean communication here? Maybe you mean synchronization (rendezvous) point. $\Rightarrow$ Communication is done at join because a thread only has two points of 687 communication with other threads: start and join.} 664 Communication is done at join because a thread only has to have to points of 665 communication with other threads: start and join. 688 666 Since a thread must be running to perform a cancellation (and cannot be 689 667 cancelled from another stack), the cancellation must be after start and 690 before the join , so join isuse.668 before the join. So join is the one that we will use. 691 669 692 670 % TODO: Find somewhere to discuss unwind collisions. … … 700 678 A coroutine stack is created for a @coroutine@ object or object that 701 679 satisfies the @is_coroutine@ trait. 702 After a coroutine stack is unwound , control returns to the @resume@function703 that most recently resumed it. The resume reports a704 @CoroutineCancelled@ exception, which contains references to the cancelled680 After a coroutine stack is unwound control returns to the resume function 681 that most recently resumed it. The resume statement reports a 682 @CoroutineCancelled@ exception, which contains a references to the cancelled 705 683 coroutine and the exception used to cancel it. 706 The @resume@function also takes the \defaultResumptionHandler{} from the707 caller's context and passes it to the internal cancellation.684 The resume function also takes the \defaultResumptionHandler{} from the 685 caller's context and passes it to the internal report. 708 686 709 687 A coroutine knows of two other coroutines, its starter and its last resumer. 710 The starter has a much more distant connection ,while the last resumer just688 The starter has a much more distant connection while the last resumer just 711 689 (in terms of coroutine state) called resume on this coroutine, so the message 712 690 is passed to the latter. -
doc/theses/andrew_beach_MMath/intro.tex
rdac16a0 r21f2e92 1 1 \chapter{Introduction} 2 2 3 \PAB{Stay in the present tense. \newline4 \url{https://plg.uwaterloo.ca/~pabuhr/technicalWriting.shtml}}5 \newline6 \PAB{Note, \lstinline{lstlisting} normally bolds keywords. None of the keywords in your thesis are bolded.}7 8 3 % Talk about Cforall and exceptions generally. 9 %This thesis goes over the design and implementation of the exception handling10 %mechanism (EHM) of11 %\CFA (pernounced sea-for-all and may be written Cforall or CFA).12 Exception handling provides alternativedynamic inter-function control flow.4 This thesis goes over the design and implementation of the exception handling 5 mechanism (EHM) of 6 \CFA (pernounced sea-for-all and may be written Cforall or CFA). 7 Exception handling provides dynamic inter-function control flow. 13 8 There are two forms of exception handling covered in this thesis: 14 9 termination, which acts as a multi-level return, 15 10 and resumption, which is a dynamic function call. 16 Note, termination exception handling is so common it is often assumed to be the only form. 17 Lesser know derivations of inter-function control flow are continuation passing in Lisp~\cite{CommonLisp}.11 This seperation is uncommon because termination exception handling is so 12 much more common that it is often assumed. 18 13 19 14 Termination exception handling allows control to return to any previous … … 36 31 37 32 % Overview of exceptions in Cforall. 38 39 \PAB{You need section titles here. Don't take them out.} 40 41 \section{Thesis Overview} 42 43 This thesis goes over the design and implementation of the exception handling 44 mechanism (EHM) of 45 \CFA (pernounced sea-for-all and may be written Cforall or CFA). 46 %This thesis describes the design and implementation of the \CFA EHM. 33 This work describes the design and implementation of the \CFA EHM. 47 34 The \CFA EHM implements all of the common exception features (or an 48 35 equivalent) found in most other EHMs and adds some features of its own. … … 65 52 66 53 % A note that yes, that was a very fast overview. 67 The design and implementation of all of \CFA's EHM's features are54 All the design and implementation of all of \CFA's EHM's features are 68 55 described in detail throughout this thesis, whether they are a common feature 69 56 or one unique to \CFA. 70 57 71 58 % The current state of the project and what it contributes. 72 All of these features have been implemented in \CFA, along with59 All of these features have been added to the \CFA implemenation, along with 73 60 a suite of test cases as part of this project. 74 61 The implementation techniques are generally applicable in other programming … … 76 63 Some parts of the EHM use other features unique to \CFA and these would be 77 64 harder to replicate in other programming languages. 78 79 \section{Background}80 65 81 66 % Talk about other programming languages. … … 85 70 Exceptions also can replace return codes and return unions. 86 71 In functional languages will also sometimes fold exceptions into monads. 87 88 \PAB{You must demonstrate knowledge of background material here.89 It should be at least a full page.}90 91 \section{Contributions}92 72 93 73 The contributions of this work are:
Note: See TracChangeset
for help on using the changeset viewer.