Changeset 21f2e92


Ignore:
Timestamp:
Jun 7, 2021, 4:00:16 PM (2 years ago)
Author:
Andrew Beach <ajbeach@…>
Branches:
ADT, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum
Children:
382edbe
Parents:
dac16a0
Message:

Revert "proofread Andrew's thesis chapters", changes saved locally.

This reverts commit 4ed7946e1c3092b517d444219a8ec8caf85a8b5a.

Location:
doc/theses/andrew_beach_MMath
Files:
3 edited

Legend:

Unmodified
Added
Removed

  • doc/theses/andrew_beach_MMath/existing.tex

    rdac16a0 r21f2e92  
    22\label{c:existing}
    33
    4 \CFA is an open-source project extending ISO C with
     4\CFA (C-for-all)~\cite{Cforall} is an open-source project extending ISO C with
    55modern safety and productivity features, while still ensuring backwards
    66compatibility with C and its programmers.  \CFA is designed to have an
    … …  
    99existing C code-base allowing programmers to learn \CFA on an as-needed basis.
    1010
    11 Only those \CFA features pertaining to this thesis are discussed.  Many of the
     11Only those \CFA features pertinent to this thesis are discussed.  Many of the
    1212\CFA syntactic and semantic features used in the thesis should be fairly
    1313obvious to the reader.
    … …  
    2929// name mangling on by default
    3030int i; // _X1ii_1
    31 @extern "C"@ {  // disables name mangling
     31extern "C" {  // disables name mangling
    3232        int j; // j
    33         @extern "Cforall"@ {  // enables name mangling
     33        extern "Cforall" {  // enables name mangling
    3434                int k; // _X1ki_1
    3535        }
    … …  
    4545\CFA adds a reference type to C as an auto-dereferencing pointer.
    4646They work very similarly to pointers.
    47 Reference-types are written the same way as a pointer-type but each
     47Reference-types are written the same way as a pointer-type is but each
    4848asterisk (@*@) is replaced with a ampersand (@&@);
    49 this includes cv-qualifiers and multiple levels of reference, \eg:
    50 
    51 \begin{minipage}{0,5\textwidth}
     49this includes cv-qualifiers and multiple levels of reference.
     50
     51They are intended for cases where you would want to use pointers but would
     52be dereferencing them (almost) every usage.
     53In most cases a reference can just be thought of as a pointer that
     54automatically puts a dereference infront of each of its uses (per-level of
     55reference).
     56The address-of operator (@&@) acts as an escape and removes one of the
     57automatic dereference operations.
     58Mutable references may be assigned to by converting them to a pointer
     59with a @&@ and then assigning a pointer too them.
     60
     61\begin{minipage}{0,45\textwidth}
    5262With references:
    5363\begin{cfa}
    … …  
    5666int && rri = ri;
    5767rri = 3;
    58 &ri = &j; // reference assignment
     68&ri = &j;
    5969ri = 5;
    6070\end{cfa}
    6171\end{minipage}
    62 \begin{minipage}{0,5\textwidth}
     72\begin{minipage}{0,45\textwidth}
    6373With pointers:
    6474\begin{cfa}
    … …  
    6777int ** ppi = &pi;
    6878**ppi = 3;
    69 pi = &j; // pointer assignment
     79pi = &j;
    7080*pi = 5;
    7181\end{cfa}
    7282\end{minipage}
    7383
    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
     86Both constructors and destructors are operators, which means they are
     87functions with special operator names rather than type names in \Cpp. The
     88special operator names may be used to call the functions explicitly (not
     89allowed in \Cpp for constructors).
    8590
    8691In general, operator names in \CFA are constructed by bracketing an operator
    … …  
    9095(such as @++?@) and post-fix operations (@?++@).
    9196
    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; }
     97The special name for a constructor is @?{}@, which comes from the
     98initialization syntax in C. That initialation syntax is also the operator
     99form. \CFA will generate a constructor call each time a variable is declared,
     100passing the initialization arguments to the constructort.
     101\begin{cfa}
     102struct Example { ... };
     103void ?{}(Example & this) { ... }
    96104{
    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}
     108void ?{}(Example & this, char first, int num) { ... }
    115109{
    116         Structure a;
    117         Structure b = {};
    118 }
    119 void ?{}(Structure & this, char first, int num) { ... }
     110        Example c = {'a', 2};
     111}
     112\end{cfa}
     113Both @a@ and @b@ will be initalized with the first constructor (there is no
     114general way to skip initialation) while @c@ will be initalized with the
     115second.
     116
     117% I don't like the \^{} symbol but $^\wedge$ isn't better.
     118Similarly destructors use the special name @^?{}@ (the @^@ has no special
     119meaning). They can be called explicatly as well but normally they are
     120implicitly called on a variable when it goes out of scope.
     121\begin{cfa}
     122void ^?{}(Example & this) { ... }
    120123{
    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;
    136125} // <- implicit destructor call
    137126\end{cfa}
    138 
    139 Whenever a type is defined, \CFA creates a default zero-argument
     127No operator name is restricted in what function signatures they may be bound
     128to although most of the forms cannot be called in operator form. Some
     129``near-misses" will generate warnings.
     130
     131Whenever a type is defined, \CFA will create a default zero-argument
    140132constructor, a copy constructor, a series of argument-per-field constructors
    141133and a destructor. All user constructors are defined after this.
    … …  
    161153char capital_a = identity( 'A' );
    162154\end{cfa}
    163 Each use of a polymorphic declaration resolves its polymorphic parameters
     155Each use of a polymorphic declaration will resolve its polymorphic parameters
    164156(in this case, just @T@) to concrete types (@int@ in the first use and @char@
    165157in the second).
    … …  
    167159To allow a polymorphic function to be separately compiled, the type @T@ must be
    168160constrained 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)
     161clauses is augmented with a list of polymorphic variables (local type names)
    170162and assertions (constraints), which represent the required operations on those
    171163types used in a function, \eg:
    172164\begin{cfa}
    173 forall( T | { void do_once(T); } )
     165forall( T | { void do_once(T); })
    174166void do_twice(T value) {
    175167        do_once(value);
    … …  
    198190void do_once(double y) { ... }
    199191int 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);
    203194        return x;
    204195}
    205196\end{cfa}
    206197Specifically, 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 the
     198argument @x@. It then looks for the most specific definition matching the
    208199assertion, which is the nested integral @do_once@ defined within the
    209200function. 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 used
    211 for the second call because the float-point argument is a better match.
     201to @do_twice@ and called within it.
     202The global definition of @do_once@ is ignored.
    212203
    213204To avoid typing long lists of assertions, constraints can be collect into
    … …  
    279270Each coroutine has a @main@ function, which takes a reference to a coroutine
    280271object and returns @void@.
    281 \begin{cfa}[numbers=left]
     272\begin{cfa}
    282273void main(CountUp & this) {
    283         for (unsigned int next = 0 ; true ; ++next) {
     274    for (unsigned int next = 0 ; true ; ++next) {
    284275                next = up;
    285276                suspend;$\label{suspend}$

  • doc/theses/andrew_beach_MMath/features.tex

    rdac16a0 r21f2e92  
    33
    44This 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.
     5exception-handling mechanism (EHM). % or exception system.
     6
     7We will begin with an overview of EHMs in general. It is not a strict
     8definition of all EHMs nor an exaustive list of all possible features.
     9However it does cover the most common structure and features found in them.
    910
    1011% We should cover what is an exception handling mechanism and what is an
    1112% exception before this. Probably in the introduction. Some of this could
    1213% move there.
    13 \section{Raise / Handle}
     14\paragraph{Raise / Handle}
    1415An exception operation has two main parts: raise and handle.
    1516These terms are sometimes also known as throw and catch but this work uses
    1617throw/catch as a particular kind of raise/handle.
    17 These are the two parts that the user writes and may
     18These are the two parts that the user will write themselves and may
    1819be the only two pieces of the EHM that have any syntax in the language.
    1920
    20 \paragraph{Raise}
     21\subparagraph{Raise}
    2122The raise is the starting point for exception handling. It marks the beginning
    22 of exception handling by raising an exception, which passes it to
     23of exception handling by raising an excepion, which passes it to
    2324the EHM.
    2425
    2526Some well known examples include the @throw@ statements of \Cpp and Java and
    26 the \code{Python}{raise} statement from Python. A raise may
    27 perform some other work (such as memory management) but for the
     27the \code{Python}{raise} statement from Python. In real systems a raise may
     28preform some other work (such as memory management) but for the
    2829purposes of this overview that can be ignored.
    2930
    30 \paragraph{Handle}
     31\subparagraph{Handle}
    3132The purpose of most exception operations is to run some user code to handle
    3233that exception. This code is given, with some other information, in a handler.
    3334
    3435A handler has three common features: the previously mentioned user code, a
    35 region of code they guard, and an exception label/condition that matches
     36region of code they cover and an exception label/condition that matches
    3637certain exceptions.
    37 Only raises inside the guarded region and raising exceptions that match the
     38Only raises inside the covered region and raising exceptions that match the
    3839label can be handled by a given handler.
    39 Different EHMs have different rules to pick a handler,
    40 if multiple handlers could be used, such as ``best match" or ``first found".
     40Different EHMs will have different rules to pick a handler
     41if multipe handlers could be used such as ``best match" or ``first found".
    4142
    4243The @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 guarded
     44also show another common feature of handlers, they are grouped by the covered
    4445region.
    4546
    46 \section{Propagation}
     47\paragraph{Propagation}
    4748After an exception is raised comes what is usually the biggest step for the
    48 EHM: finding and setting up the handler. The propagation from raise to
     49EHM: finding and setting up the handler. The propogation from raise to
    4950handler 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}
     51matching against the handler and installing the handler.
     52
     53\subparagraph{Searching}
    5354The EHM begins by searching for handlers that might be used to handle
    5455the exception. Searching is usually independent of the exception that was
    55 thrown as it looks for handlers that have the raise site in their guarded
     56thrown as it looks for handlers that have the raise site in their covered
    5657region.
    57 This search includes handlers in the current function, as well as any in callers
    58 on the stack that have the function call in their guarded region.
    59 
    60 \paragraph{Matching}
     58This includes handlers in the current function, as well as any in callers
     59on the stack that have the function call in their covered region.
     60
     61\subparagraph{Matching}
    6162Each handler found has to be matched with the raised exception. The exception
    62 label defines a condition that is used with the exception to decide if
     63label defines a condition that be use used with exception and decides if
    6364there is a match or not.
    6465
    65 In languages where the first match is used, this step is intertwined with
    66 searching: a match check is performed immediately after the search finds
     66In languages where the first match is used this step is intertwined with
     67searching, a match check is preformed immediately after the search finds
    6768a possible handler.
    6869
    69 \section{Installing}
     70\subparagraph{Installing}
    7071After a handler is chosen it must be made ready to run.
    7172The implementation can vary widely to fit with the rest of the
    … …  
    7475case when stack unwinding is involved.
    7576
    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}
     77If a matching handler is not guarantied to be found the EHM will need a
     78different course of action here in the cases where no handler matches.
     79This is only required with unchecked exceptions as checked exceptions
     80(such as in Java) can make than guaranty.
     81This different action can also be installing a handler but it is usually an
     82implicat and much more general one.
     83
     84\subparagraph{Hierarchy}
    8385A common way to organize exceptions is in a hierarchical structure.
    84 This organization is often used in object-orientated languages where the
     86This is especially true in object-orientated languages where the
    8587exception hierarchy is a natural extension of the object hierarchy.
    8688
    … …  
    111113
    112114The EHM can return control to many different places,
    113 the most common are after the handler definition (termination) and after the raise (resumption).
     115the most common are after the handler definition and after the raise.
    114116
    115117\paragraph{Communication}
    116118For effective exception handling, additional information is often passed
    117 from the raise to the handler and back again.
     119from the raise to the handler.
    118120So far only communication of the exceptions' identity has been covered.
    119 A common communication method is putting fields into the exception instance and giving the
    120 handler access to them. References in the exception instance can push data back to the raise.
     121A common method is putting fields into the exception instance and giving the
     122handler access to them.
    121123
    122124\section{Virtuals}
    123125Virtual types and casts are not part of \CFA's EHM nor are they required for
    124126any EHM.
    125 However, one of the best ways to support an exception hierarchy is via a virtual system
    126 among exceptions and used for exception matching.
    127 
    128 Ideally, the virtual system would have been part of \CFA before the work
     127However the \CFA uses a hierarchy built with the virtual system as the basis
     128for exceptions and exception matching.
     129
     130The virtual system would have ideally been part of \CFA before the work
    129131on exception handling began, but unfortunately it was not.
    130 Therefore, only the features and framework needed for the EHM were
     132Because of this only the features and framework needed for the EHM were
    131133designed and implemented. Other features were considered to ensure that
    132 the structure could accommodate other desirable features in the future but they were not
     134the structure could accomidate other desirable features but they were not
    133135implemented.
    134 The rest of this section discusses the implemented subset of the
    135 virtual-system design.
     136The rest of this section will only discuss the finalized portion of the
     137virtual system.
    136138
    137139The virtual system supports multiple ``trees" of types. Each tree is
    … …  
    143145% A type's ancestors are its parent and its parent's ancestors.
    144146% The root type has no ancestors.
    145 % A type's decedents are its children and its children's decedents.
     147% A type's decendents are its children and its children's decendents.
    146148
    147149Every virtual type also has a list of virtual members. Children inherit
    … …  
    149151It is important to note that these are virtual members, not virtual methods
    150152of object-orientated programming, and can be of any type.
    151 
    152 \PAB{I do not understand these sentences. Can you add an example? $\Rightarrow$
    153153\CFA still supports virtual methods as a special case of virtual members.
    154 Function pointers that take a pointer to the virtual type are modified
     154Function pointers that take a pointer to the virtual type will be modified
    155155with each level of inheritance so that refers to the new type.
    156156This means an object can always be passed to a function in its virtual table
    157 as if it were a method.}
     157as if it were a method.
    158158
    159159Each virtual type has a unique id.
    160 This id and all the virtual members are combined
     160This unique id and all the virtual members are combined
    161161into a virtual table type. Each virtual type has a pointer to a virtual table
    162162as a hidden field.
    163 
    164 \PAB{God forbid, maybe you need a UML diagram to relate these entities.}
    165163
    166164Up until this point the virtual system is similar to ones found in
    167165object-orientated languages but this where \CFA diverges. Objects encapsulate a
    168166single set of behaviours in each type, universally across the entire program,
    169 and indeed all programs that use that type definition. In this sense, the
     167and indeed all programs that use that type definition. In this sense the
    170168types are ``closed" and cannot be altered.
    171169
    172 In \CFA, types do not encapsulate any behaviour. Traits are local and
    173 types can begin to satisfy a trait, stop satisfying a trait or satisfy the same
     170In \CFA types do not encapsulate any behaviour. Traits are local and
     171types can begin to statify a trait, stop satifying a trait or satify the same
    174172trait 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 capability means it
    176 is impossible to pick a single set of functions that represent the type's
     173In this sense they are ``open" as they can change at any time. This means it
     174is implossible to pick a single set of functions that repersent the type's
    177175implementation across the program.
    178176
    179177\CFA side-steps this issue by not having a single virtual table for each
    180 type. A user can define virtual tables that are filled in at their
    181 declaration and given a name. Anywhere that name is visible, even if
    182 defined locally inside a function (although that means it does not have a
     178type. A user can define virtual tables which are filled in at their
     179declaration and given a name. Anywhere that name is visible, even if it was
     180defined locally inside a function (although that means it will not have a
    183181static lifetime), it can be used.
    184 Specifically, a virtual type is ``bound" to a virtual table that
     182Specifically, a virtual type is ``bound" to a virtual table which
    185183sets the virtual members for that object. The virtual members can be accessed
    186184through the object.
    187185
    188 \PAB{The above explanation is very good!}
    189 
    190186While much of the virtual infrastructure is created, it is currently only used
    191187internally for exception handling. The only user-level feature is the virtual
    192 cast
     188cast, which is the same as the \Cpp \code{C++}{dynamic_cast}.
    193189\label{p:VirtualCast}
    194190\begin{cfa}
    195191(virtual TYPE)EXPRESSION
    196192\end{cfa}
    197 which is the same as the \Cpp \code{C++}{dynamic_cast}.
    198193Note, the syntax and semantics matches a C-cast, rather than the function-like
    199194\Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be
    … …  
    217212\end{cfa}
    218213The 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 currently the trait system
    221 cannot express them (adding such assertions would be part of
     214type. Each exception type should have but a single virtual table type.
     215Now there are no actual assertions in this trait because the trait system
     216actually can't express them (adding such assertions would be part of
    222217completing the virtual system). The imaginary assertions would probably come
    223218from a trait defined by the virtual system, and state that the exception type
    224 is a virtual type, is a descendent of @exception_t@ (the base exception type)
     219is a virtual type, is a decendent of @exception_t@ (the base exception type)
    225220and note its virtual table type.
    226221
    … …  
    241236};
    242237\end{cfa}
    243 Both traits ensure a pair of types are an exception type and its virtual table,
     238Both traits ensure a pair of types are an exception type and its virtual table
    244239and defines one of the two default handlers. The default handlers are used
    245240as fallbacks and are discussed in detail in \vref{s:ExceptionHandling}.
    … …  
    269264\section{Exception Handling}
    270265\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.
    272267These twin operations are the core of \CFA's exception handling mechanism.
    273 This section covers the general patterns shared by the two operations and
    274 then go on to cover the details of each individual operation.
     268This section will cover the general patterns shared by the two operations and
     269then go on to cover the details each individual operation.
    275270
    276271Both operations follow the same set of steps.
    277 Both start with the user performing a raise on an exception.
    278 Then the exception propagates up the stack.
     272Both start with the user preforming a raise on an exception.
     273Then the exception propogates up the stack.
    279274If 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, control
    282 continues after the raise. Note, the default handler may further change control flow rather than return.
     275After that control returns to normal execution.
     276If the search fails a default handler is run and then control
     277returns to normal execution after the raise.
    283278
    284279This general description covers what the two kinds have in common.
    285 Differences include how propagation is performed, where exception continues
     280Differences include how propogation is preformed, where exception continues
    286281after an exception is caught and handled and which default handler is run.
    287282
    288283\subsection{Termination}
    289284\label{s:Termination}
    290 
    291285Termination handling is the familiar kind and used in most programming
    292286languages with exception handling.
    293 It is a dynamic, non-local goto. If the raised exception is matched and
    294 handled, the stack is unwound and control (usually) continues in the function
     287It is dynamic, non-local goto. If the raised exception is matched and
     288handled the stack is unwound and control will (usually) continue the function
    295289on the call stack that defined the handler.
    296290Termination is commonly used when an error has occurred and recovery is
    … …  
    307301termination exception is any type that satisfies the trait
    308302@is_termination_exception@ at the call site.
    309 Through \CFA's trait system, the trait functions are implicitly passed into the
     303Through \CFA's trait system the trait functions are implicity passed into the
    310304throw code and the EHM.
    311305A new @defaultTerminationHandler@ can be defined in any scope to
    312 change the throw's behaviour (see below).
    313 
    314 The throw copies the provided exception into managed memory to ensure
    315 the exception is not destroyed when the stack is unwound.
     306change the throw's behavior (see below).
     307
     308The throw will copy the provided exception into managed memory to ensure
     309the exception is not destroyed if the stack is unwound.
    316310It is the user's responsibility to ensure the original exception is cleaned
    317 up whether the stack is unwound or not. Allocating it on the stack is
     311up wheither the stack is unwound or not. Allocating it on the stack is
    318312usually sufficient.
    319313
    320 Then propagation starts the search. \CFA uses a ``first match" rule so
    321 matching is performed with the copied exception as the search continues.
    322 It starts from the throwing function and proceeds towards the base of the stack,
     314Then propogation starts with the search. \CFA uses a ``first match" rule so
     315matching is preformed with the copied exception as the search continues.
     316It starts from the throwing function and proceeds to the base of the stack,
    323317from callee to caller.
    324318At each stack frame, a check is made for resumption handlers defined by the
    … …  
    333327}
    334328\end{cfa}
    335 When viewed on its own, a try statement simply executes the statements
    336 in \snake{GUARDED_BLOCK} and when those are finished, the try statement finishes.
     329When viewed on its own, a try statement will simply execute the statements
     330in \snake{GUARDED_BLOCK} and when those are finished the try statement finishes.
    337331
    338332However, while the guarded statements are being executed, including any
    339 invoked functions, all the handlers in these statements are included on the search
    340 path. Hence, if a termination exception is raised, the search includes the added handlers associated with the guarded block and those further up the
    341 stack from the guarded block.
     333invoked functions, all the handlers in the statement are now on the search
     334path. If a termination exception is thrown and not handled further up the
     335stack they will be matched against the exception.
    342336
    343337Exception matching checks the handler in each catch clause in the order
    344 they appear, top to bottom. If the representation of the raised exception type
     338they appear, top to bottom. If the representation of the thrown exception type
    345339is 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 in
    347 @HANDLER_BLOCK@$_i$ are executed.
    348 If control reaches the end of the handler, the exception is
     340(if provided) is
     341bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
     342are executed. If control reaches the end of the handler, the exception is
    349343freed and control continues after the try statement.
    350344
    351 If no termination handler is found during the search, the default handler
    352 (\defaultTerminationHandler) visible at the raise statement is called.
    353 Through \CFA's trait system, the best match at the raise sight is used.
    354 This function is run and is passed the copied exception. If the default
    355 handler returns, control continues after the throw statement.
     345If no termination handler is found during the search then the default handler
     346(\defaultTerminationHandler) is run.
     347Through \CFA's trait system the best match at the throw sight will be used.
     348This function is run and is passed the copied exception. After the default
     349handler is run control continues after the throw statement.
    356350
    357351There is a global @defaultTerminationHandler@ that is polymorphic over all
    358 termination exception types. Since it is so general, a more specific handler can be
    359 defined and is used for those types, effectively overriding the handler
    360 for a particular exception type.
     352exception types. Since it is so general a more specific handler can be
     353defined and will be used for those types, effectively overriding the handler
     354for particular exception type.
    361355The global default termination handler performs a cancellation
    362356(see \vref{s:Cancellation}) on the current stack with the copied exception.
    … …  
    368362just as old~\cite{Goodenough75} and is simpler in many ways.
    369363It 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.}
     364matched a closure will be taken from up the stack and executed,
     365after which the raising function will continue executing.
     366These are most often used when an error occurred and if the error is repaired
     367then the function can continue.
    379368
    380369A resumption raise is started with the @throwResume@ statement:
    … …  
    387376@is_resumption_exception@ at the call site.
    388377The 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 and
    393 any values on the stack remain in scope, while the resumption is handled.
     378the exception system while handling the exception.
     379
     380At run-time, no exception copy is made.
     381As the stack is not unwound the exception and
     382any values on the stack will remain in scope while the resumption is handled.
    394383
    395384The EHM then begins propogation. The search starts from the raise in the
    396 resuming function and proceeds towards the base of the stack, from callee to caller.
     385resuming function and proceeds to the base of the stack, from callee to caller.
    397386At each stack frame, a check is made for resumption handlers defined by the
    398387@catchResume@ clauses of a @try@ statement.
    … …  
    409398Note that termination handlers and resumption handlers may be used together
    410399in a single try statement, intermixing @catch@ and @catchResume@ freely.
    411 Each type of handler only interacts with exceptions from the matching
    412 kind of raise.
    413 When a try statement is executed, it simply executes the statements in the
    414 @GUARDED_BLOCK@ and then returns.
     400Each type of handler will only interact with exceptions from the matching
     401type of raise.
     402When a try statement is executed it simply executes the statements in the
     403@GUARDED_BLOCK@ and then finishes.
    415404
    416405However, while the guarded statements are being executed, including any
    417 invoked functions, all the handlers in these statements are included on the search
    418 path. Hence, if a resumption exception is raised the search includes the added handlers associated with the guarded block and those further up the
    419 stack from the guarded block.
     406invoked functions, all the handlers in the statement are now on the search
     407path. If a resumption exception is reported and not handled further up the
     408stack they will be matched against the exception.
    420409
    421410Exception matching checks the handler in each catch clause in the order
    422 they appear, top to bottom. If the representation of the raised exception type
     411they appear, top to bottom. If the representation of the thrown exception type
    423412is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
    424413(if provided) is bound to a pointer to the exception and the statements in
    … …  
    427416the raise statement that raised the handled exception.
    428417
    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
     418Like termination, if no resumption handler is found, the default handler
     419visible at the throw statement is called. It will use the best match at the
     420call sight according to \CFA's overloading rules. The default handler is
    433421passed the exception given to the throw. When the default handler finishes
    434422execution continues after the raise statement.
    435423
    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
     424There is a global \defaultResumptionHandler{} is polymorphic over all
     425termination exceptions and preforms a termination throw on the exception.
     426The \defaultTerminationHandler{} for that raise is matched at the
     427original raise statement (the resumption @throw@\-@Resume@) and it can be
    439428customized by introducing a new or better match as well.
    440429
    441430\subsubsection{Resumption Marking}
    442431\label{s:ResumptionMarking}
    443 
    444432A key difference between resumption and termination is that resumption does
    445433not 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 statement
    447 searched before it are still on the stack. Their existence can lead to the recursive
     434and run it's try block (the guarded statements) and every try statement
     435searched before it are still on the stack. This can lead to the recursive
    448436resumption problem.
    449437
    … …  
    458446}
    459447\end{cfa}
    460 When this code is executed, the guarded @throwResume@ starts a
    461 search and matchs the handler in the @catchResume@ clause. This
    462 call is placed on the top of stack above the try-block. The second throw
    463 searchs the same try block and puts call another instance of the
    464 same handler on the stack leading to an infinite recursion.
    465 
    466 While this situation is trivial and easy to avoid, much more complex cycles
     448When this code is executed the guarded @throwResume@ will throw, start a
     449search and match the handler in the @catchResume@ clause. This will be
     450call and placed on the stack on top of the try-block. The second throw then
     451throws and will search the same try block and put call another instance of the
     452same handler leading to an infinite loop.
     453
     454This situation is trivial and easy to avoid, but much more complex cycles
    467455can form with multiple handlers and different exception types.
    468456
    469 To prevent all of these cases, the exception search marks the try statements it visits.
     457To prevent all of these cases we mark try statements on the stack.
    470458A try statement is marked when a match check is preformed with it and an
    471 exception. The statement is unmarked when the handling of that exception
     459exception. The statement will be unmarked when the handling of that exception
    472460is completed or the search completes without finding a handler.
    473 While a try statement is marked, its handlers are never matched, effectify
    474 skipping over them to the next try statement.
     461While a try statement is marked its handlers are never matched, effectify
     462skipping over it to the next try statement.
    475463
    476464\begin{center}
    … …  
    479467
    480468These rules mirror what happens with termination.
    481 When a termination throw happens in a handler, the search does not look at
     469When a termination throw happens in a handler the search will not look at
    482470any handlers from the original throw to the original catch because that
    483 part of the stack is unwound.
     471part of the stack has been unwound.
    484472A 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 sections
    486 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 but
    490 lack the symmetry, meaning there are more rules to remember.
     473but it will not try to match the exception with try statements in the section
     474that would have been unwound as they are marked.
     475
     476The symmetry between resumption termination is why this pattern was picked.
     477Other patterns, such as marking just the handlers that caught, also work but
     478lack the symmetry means there are more rules to remember.
    491479
    492480\section{Conditional Catch}
    493 
    494481Both termination and resumption handler clauses can be given an additional
    495482condition to further control which exceptions they handle:
    … …  
    504491did not match.
    505492
    506 The condition matching allows finer matching to check
     493The condition matching allows finer matching by allowing the match to check
    507494more kinds of information than just the exception type.
    508495\begin{cfa}
    … …  
    519506// Can't handle a failure relating to f2 here.
    520507\end{cfa}
    521 In this example, the file that experianced the IO error is used to decide
     508In this example the file that experianced the IO error is used to decide
    522509which handler should be run, if any at all.
    523510
    … …  
    548535
    549536\subsection{Comparison with Reraising}
    550 
    551537A 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.
     538the exception after it has been caught if it could not be handled here.
    553539On the surface these two features seem interchangable.
    554540
    555 If @throw@ is used to start a termination reraise then these two statements
    556 have the same behaviour:
     541If we used @throw;@ to start a termination reraise then these two statements
     542would have the same behaviour:
    557543\begin{cfa}
    558544try {
    … …  
    574560}
    575561\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
     562If there are further handlers after this handler only the first version will
     563check them. If multiple handlers on a single try block that could handle the
     564same exception the translations get more complex but they are equivilantly
     565powerful.
     566
     567Until stack unwinding comes into the picture. In termination handling, a
    587568conditional catch happens before the stack is unwound, but a reraise happens
    588569afterwards. Normally this might only cause you to loose some debug
    589570information you could get from a stack trace (and that can be side stepped
    590571entirely by collecting information during the unwind). But for \CFA there is
    591 another issue, if the exception is not handled the default handler should be
     572another issue, if the exception isn't handled the default handler should be
    592573run at the site of the original raise.
    593574
    594 There are two problems with this: the site of the original raise does not
    595 exist anymore and the default handler might not exist anymore. The site is
    596 always removed as part of the unwinding, often with the entirety of the
     575There are two problems with this: the site of the original raise doesn't
     576exist anymore and the default handler might not exist anymore. The site will
     577always be removed as part of the unwinding, often with the entirety of the
    597578function it was in. The default handler could be a stack allocated nested
    598579function removed during the unwind.
    … …  
    605586\section{Finally Clauses}
    606587\label{s:FinallyClauses}
    607 
    608588Finally clauses are used to preform unconditional clean-up when leaving a
    609589scope and are placed at the end of a try statement after any handler clauses:
    … …  
    618598The @FINALLY_BLOCK@ is executed when the try statement is removed from the
    619599stack, including when the @GUARDED_BLOCK@ finishes, any termination handler
    620 finishes, or during an unwind.
     600finishes or during an unwind.
    621601The only time the block is not executed is if the program is exited before
    622602the stack is unwound.
    … …  
    634614
    635615Not all languages with unwinding have finally clauses. Notably \Cpp does
    636 without it as destructors with RAII serve a similar role. Although destructors and
    637 finally clauses have overlapping usage cases, they have their own
    638 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.
     616without it as descructors serve a similar role. Although destructors and
     617finally clauses can be used in many of the same areas they have their own
     618use cases like top-level functions and lambda functions with closures.
     619Destructors take a bit more work to set up but are much easier to reuse while
     620finally clauses are good for one-off uses and
     621can easily include local information.
    642622
    643623\section{Cancellation}
    … …  
    652632raise, this exception is not used in matching only to pass information about
    653633the cause of the cancellation.
    654 (This restriction also means matching cannot fail so there is no default handler.)
     634(This also means matching cannot fail so there is no default handler.)
    655635
    656636After @cancel_stack@ is called the exception is copied into the EHM's memory
    657637and the current stack is
    658 unwound.
    659 The result of a cancellation depends on the kind of stack that is being unwound.
     638unwound. After that it depends one which stack is being cancelled.
    660639
    661640\paragraph{Main Stack}
    … …  
    664643After the main stack is unwound there is a program-level abort.
    665644
    666 There are two reasons for this semantics. The first is that it obviously had to do the abort
     645There are two reasons for this. The first is that it obviously had to do this
    667646in a sequential program as there is nothing else to notify and the simplicity
    668647of 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 connection
    670 to, so it would have be explicitly managed.}
     648Also, even in concurrent programs there is no stack that an innate connection
     649to, so it would have be explicitly managed.
    671650
    672651\paragraph{Thread Stack}
    673652A thread stack is created for a \CFA @thread@ object or object that satisfies
    674653the @is_thread@ trait.
    675 After a thread stack is unwound, the exception is stored until another
     654After a thread stack is unwound there exception is stored until another
    676655thread attempts to join with it. Then the exception @ThreadCancelled@,
    677656which stores a reference to the thread and to the exception passed to the
    678 cancellation, is reported from the join to the joining thread.
     657cancellation, is reported from the join.
    679658There is one difference between an explicit join (with the @join@ function)
    680659and an implicit join (from a destructor call). The explicit join takes the
    681660default handler (@defaultResumptionHandler@) from its calling context while
    682 the implicit join provides its own, which does a program abort if the
     661the implicit join provides its own which does a program abort if the
    683662@ThreadCancelled@ exception cannot be handled.
    684663
    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.}
     664Communication is done at join because a thread only has to have to points of
     665communication with other threads: start and join.
    688666Since a thread must be running to perform a cancellation (and cannot be
    689667cancelled from another stack), the cancellation must be after start and
    690 before the join, so join is use.
     668before the join. So join is the one that we will use.
    691669
    692670% TODO: Find somewhere to discuss unwind collisions.
    … …  
    700678A coroutine stack is created for a @coroutine@ object or object that
    701679satisfies the @is_coroutine@ trait.
    702 After a coroutine stack is unwound, control returns to the @resume@ function
    703 that most recently resumed it. The resume reports a
    704 @CoroutineCancelled@ exception, which contains references to the cancelled
     680After a coroutine stack is unwound control returns to the resume function
     681that most recently resumed it. The resume statement reports a
     682@CoroutineCancelled@ exception, which contains a references to the cancelled
    705683coroutine and the exception used to cancel it.
    706 The @resume@ function also takes the \defaultResumptionHandler{} from the
    707 caller's context and passes it to the internal cancellation.
     684The resume function also takes the \defaultResumptionHandler{} from the
     685caller's context and passes it to the internal report.
    708686
    709687A 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 just
     688The starter has a much more distant connection while the last resumer just
    711689(in terms of coroutine state) called resume on this coroutine, so the message
    712690is passed to the latter.

  • doc/theses/andrew_beach_MMath/intro.tex

    rdac16a0 r21f2e92  
    11\chapter{Introduction}
    22
    3 \PAB{Stay in the present tense. \newline
    4 \url{https://plg.uwaterloo.ca/~pabuhr/technicalWriting.shtml}}
    5 \newline
    6 \PAB{Note, \lstinline{lstlisting} normally bolds keywords. None of the keywords in your thesis are bolded.}
    7 
    83% Talk about Cforall and exceptions generally.
    9 %This thesis goes over the design and implementation of the exception handling
    10 %mechanism (EHM) of
    11 %\CFA (pernounced sea-for-all and may be written Cforall or CFA).
    12 Exception handling provides alternative dynamic inter-function control flow.
     4This thesis goes over the design and implementation of the exception handling
     5mechanism (EHM) of
     6\CFA (pernounced sea-for-all and may be written Cforall or CFA).
     7Exception handling provides dynamic inter-function control flow.
    138There are two forms of exception handling covered in this thesis:
    149termination, which acts as a multi-level return,
    1510and 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}.
     11This seperation is uncommon because termination exception handling is so
     12much more common that it is often assumed.
    1813
    1914Termination exception handling allows control to return to any previous
    … …  
    3631
    3732% 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.
     33This work describes the design and implementation of the \CFA EHM.
    4734The \CFA EHM implements all of the common exception features (or an
    4835equivalent) found in most other EHMs and adds some features of its own.
    … …  
    6552
    6653% A note that yes, that was a very fast overview.
    67 The design and implementation of all of \CFA's EHM's features are
     54All the design and implementation of all of \CFA's EHM's features are
    6855described in detail throughout this thesis, whether they are a common feature
    6956or one unique to \CFA.
    7057
    7158% The current state of the project and what it contributes.
    72 All of these features have been implemented in \CFA, along with
     59All of these features have been added to the \CFA implemenation, along with
    7360a suite of test cases as part of this project.
    7461The implementation techniques are generally applicable in other programming
    … …  
    7663Some parts of the EHM use other features unique to \CFA and these would be
    7764harder to replicate in other programming languages.
    78 
    79 \section{Background}
    8065
    8166% Talk about other programming languages.
    … …  
    8570Exceptions also can replace return codes and return unions.
    8671In 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}
    9272
    9373The contributions of this work are:
Note: See TracChangeset for help on using the changeset viewer.