Changeset 4ed7946e for doc/theses


Ignore:
Timestamp:
Jun 4, 2021, 11:24:41 AM (3 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum
Children:
53692b3, 9e67e92
Parents:
553f8abe
Message:

proofread Andrew's thesis chapters

Location:
doc/theses/andrew_beach_MMath
Files:
3 edited

Legend:

Unmodified
Added
Removed

  • doc/theses/andrew_beach_MMath/existing.tex

    r553f8abe r4ed7946e  
    22\label{c:existing}
    33
    4 \CFA (C-for-all)~\cite{Cforall} is an open-source project extending ISO C with
     4\CFA 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 pertinent to this thesis are discussed.  Many of the
     11Only those \CFA features pertaining 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
     31@extern "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 is but each
     47Reference-types are written the same way as a pointer-type but each
    4848asterisk (@*@) is replaced with a ampersand (@&@);
    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}
     49this includes cv-qualifiers and multiple levels of reference, \eg:
     50
     51\begin{minipage}{0,5\textwidth}
    6252With references:
    6353\begin{cfa}
    … …  
    6656int && rri = ri;
    6757rri = 3;
    68 &ri = &j;
     58&ri = &j; // reference assignment
    6959ri = 5;
    7060\end{cfa}
    7161\end{minipage}
    72 \begin{minipage}{0,45\textwidth}
     62\begin{minipage}{0,5\textwidth}
    7363With pointers:
    7464\begin{cfa}
    … …  
    7767int ** ppi = &pi;
    7868**ppi = 3;
    79 pi = &j;
     69pi = &j; // pointer assignment
    8070*pi = 5;
    8171\end{cfa}
    8272\end{minipage}
    8373
    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).
     74References are intended for cases where you would want to use pointers but would
     75be dereferencing them (almost) every usage.
     76In most cases a reference can just be thought of as a pointer that
     77automatically puts a dereference in front of each of its uses (per-level of
     78reference).
     79The address-of operator (@&@) acts as an escape and removes one of the
     80automatic dereference operations.
     81Mutable references may be assigned by converting them to a pointer
     82with a @&@ and then assigning a pointer to them, as in @&ri = &j;@ above.
     83
     84\section{Operators}
    9085
    9186In general, operator names in \CFA are constructed by bracketing an operator
    … …  
    9590(such as @++?@) and post-fix operations (@?++@).
    9691
    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) { ... }
    104 {
    105         Example a;
    106         Example b = {};
    107 }
    108 void ?{}(Example & this, char first, int num) { ... }
    109 {
    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.
     92An operator name may describe any function signature (it is just a name) but
     93only certain signatures may be called in operator form.
     94\begin{cfa}
     95int ?+?( int i, int j, int k ) { return i + j + k; }
     96{
     97        sout | ?+?( 3, 4, 5 ); // no infix form
     98}
     99\end{cfa}
     100Some ``near-misses" for unary/binary operator prototypes generate warnings.
     101
     102Both constructors and destructors are operators, which means they are
     103functions with special operator names rather than type names in \Cpp. The
     104special operator names may be used to call the functions explicitly (not
     105allowed in \Cpp for constructors).
     106
     107The special name for a constructor is @?{}@, where the name @{}@ comes from the
     108initialization 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,
     111passing the initialization arguments to the constructor.
     112\begin{cfa}
     113struct Structure { ... };
     114void ?{}(Structure & this) { ... }
     115{
     116        Structure a;
     117        Structure b = {};
     118}
     119void ?{}(Structure & this, char first, int num) { ... }
     120{
     121        Structure c = {'a', 2};
     122}
     123\end{cfa}
     124Both @a@ and @b@ are initialized with the first constructor,
     125while @c@ is initialized with the second.
     126Currently, there is no general way to skip initialization.
    116127
    117128% 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) { ... }
    123 {
    124     Example d;
     129Similarly, destructors use the special name @^?{}@ (the @^@ has no special
     130meaning).  Normally, they are implicitly called on a variable when it goes out
     131of scope but they can be called explicitly as well.
     132\begin{cfa}
     133void ^?{}(Structure & this) { ... }
     134{
     135        Structure d;
    125136} // <- implicit destructor call
    126137\end{cfa}
    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
     138
     139Whenever a type is defined, \CFA creates a default zero-argument
    132140constructor, a copy constructor, a series of argument-per-field constructors
    133141and a destructor. All user constructors are defined after this.
    … …  
    153161char capital_a = identity( 'A' );
    154162\end{cfa}
    155 Each use of a polymorphic declaration will resolve its polymorphic parameters
     163Each use of a polymorphic declaration resolves its polymorphic parameters
    156164(in this case, just @T@) to concrete types (@int@ in the first use and @char@
    157165in the second).
    … …  
    159167To allow a polymorphic function to be separately compiled, the type @T@ must be
    160168constrained by the operations used on @T@ in the function body. The @forall@
    161 clauses is augmented with a list of polymorphic variables (local type names)
     169clause is augmented with a list of polymorphic variables (local type names)
    162170and assertions (constraints), which represent the required operations on those
    163171types used in a function, \eg:
    164172\begin{cfa}
    165 forall( T | { void do_once(T); })
     173forall( T | { void do_once(T); } )
    166174void do_twice(T value) {
    167175        do_once(value);
    … …  
    190198void do_once(double y) { ... }
    191199int quadruple(int x) {
    192         void do_once(int y) { y = y * 2; }
    193         do_twice(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
    194203        return x;
    195204}
    196205\end{cfa}
    197206Specifically, the complier deduces that @do_twice@'s T is an integer from the
    198 argument @x@. It then looks for the most specific definition matching the
     207argument @x@. It then looks for the most \emph{specific} definition matching the
    199208assertion, which is the nested integral @do_once@ defined within the
    200209function. The matched assertion function is then passed as a function pointer
    201 to @do_twice@ and called within it.
    202 The global definition of @do_once@ is ignored.
     210to @do_twice@ and called within it.  The global definition of @do_once@ is used
     211for the second call because the float-point argument is a better match.
    203212
    204213To avoid typing long lists of assertions, constraints can be collect into
    … …  
    270279Each coroutine has a @main@ function, which takes a reference to a coroutine
    271280object and returns @void@.
    272 \begin{cfa}
     281\begin{cfa}[numbers=left]
    273282void main(CountUp & this) {
    274     for (unsigned int next = 0 ; true ; ++next) {
     283        for (unsigned int next = 0 ; true ; ++next) {
    275284                next = up;
    276285                suspend;$\label{suspend}$

  • doc/theses/andrew_beach_MMath/features.tex

    r553f8abe r4ed7946e  
    33
    44This chapter covers the design and user interface of the \CFA
    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.
     5EHM, % or exception system.
     6and begins with a general overview of EHMs. It is not a strict
     7definition of all EHMs nor an exhaustive list of all possible features.
     8However it does cover the most common structures and features found in them.
    109
    1110% We should cover what is an exception handling mechanism and what is an
    1211% exception before this. Probably in the introduction. Some of this could
    1312% move there.
    14 \paragraph{Raise / Handle}
     13\section{Raise / Handle}
    1514An exception operation has two main parts: raise and handle.
    1615These terms are sometimes also known as throw and catch but this work uses
    1716throw/catch as a particular kind of raise/handle.
    18 These are the two parts that the user will write themselves and may
     17These are the two parts that the user writes and may
    1918be the only two pieces of the EHM that have any syntax in the language.
    2019
    21 \subparagraph{Raise}
     20\paragraph{Raise}
    2221The raise is the starting point for exception handling. It marks the beginning
    23 of exception handling by raising an excepion, which passes it to
     22of exception handling by raising an exception, which passes it to
    2423the EHM.
    2524
    2625Some well known examples include the @throw@ statements of \Cpp and Java and
    27 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
     26the \code{Python}{raise} statement from Python. A raise may
     27perform some other work (such as memory management) but for the
    2928purposes of this overview that can be ignored.
    3029
    31 \subparagraph{Handle}
     30\paragraph{Handle}
    3231The purpose of most exception operations is to run some user code to handle
    3332that exception. This code is given, with some other information, in a handler.
    3433
    3534A handler has three common features: the previously mentioned user code, a
    36 region of code they cover and an exception label/condition that matches
     35region of code they guard, and an exception label/condition that matches
    3736certain exceptions.
    38 Only raises inside the covered region and raising exceptions that match the
     37Only raises inside the guarded region and raising exceptions that match the
    3938label can be handled by a given handler.
    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".
     39Different EHMs have different rules to pick a handler,
     40if multiple handlers could be used, such as ``best match" or ``first found".
    4241
    4342The @try@ statements of \Cpp, Java and Python are common examples. All three
    44 also show another common feature of handlers, they are grouped by the covered
     43also show another common feature of handlers, they are grouped by the guarded
    4544region.
    4645
    47 \paragraph{Propagation}
     46\section{Propagation}
    4847After an exception is raised comes what is usually the biggest step for the
    49 EHM: finding and setting up the handler. The propogation from raise to
     48EHM: finding and setting up the handler. The propagation from raise to
    5049handler can be broken up into three different tasks: searching for a handler,
    51 matching against the handler and installing the handler.
    52 
    53 \subparagraph{Searching}
     50matching against the handler, and installing the handler.
     51
     52\paragraph{Searching}
    5453The EHM begins by searching for handlers that might be used to handle
    5554the exception. Searching is usually independent of the exception that was
    56 thrown as it looks for handlers that have the raise site in their covered
     55thrown as it looks for handlers that have the raise site in their guarded
    5756region.
    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}
     57This search includes handlers in the current function, as well as any in callers
     58on the stack that have the function call in their guarded region.
     59
     60\paragraph{Matching}
    6261Each handler found has to be matched with the raised exception. The exception
    63 label defines a condition that be use used with exception and decides if
     62label defines a condition that is used with the exception to decide if
    6463there is a match or not.
    6564
    66 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
     65In languages where the first match is used, this step is intertwined with
     66searching: a match check is performed immediately after the search finds
    6867a possible handler.
    6968
    70 \subparagraph{Installing}
     69\section{Installing}
    7170After a handler is chosen it must be made ready to run.
    7271The implementation can vary widely to fit with the rest of the
    … …  
    7574case when stack unwinding is involved.
    7675
    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}
     76If a matching handler is not guarantied to be found, the EHM needs a
     77different course of action for the case where no handler matches.
     78This situation only occurs with unchecked exceptions as checked exceptions
     79(such as in Java) can make the guarantee.
     80This unhandled action can abort the program or install a very general handler.
     81
     82\paragraph{Hierarchy}
    8583A common way to organize exceptions is in a hierarchical structure.
    86 This is especially true in object-orientated languages where the
     84This organization is often used in object-orientated languages where the
    8785exception hierarchy is a natural extension of the object hierarchy.
    8886
    … …  
    113111
    114112The EHM can return control to many different places,
    115 the most common are after the handler definition and after the raise.
     113the most common are after the handler definition (termination) and after the raise (resumption).
    116114
    117115\paragraph{Communication}
    118116For effective exception handling, additional information is often passed
    119 from the raise to the handler.
     117from the raise to the handler and back again.
    120118So far only communication of the exceptions' identity has been covered.
    121 A common method is putting fields into the exception instance and giving the
    122 handler access to them.
     119A common communication method is putting fields into the exception instance and giving the
     120handler access to them. References in the exception instance can push data back to the raise.
    123121
    124122\section{Virtuals}
    125123Virtual types and casts are not part of \CFA's EHM nor are they required for
    126124any EHM.
    127 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
     125However, one of the best ways to support an exception hierarchy is via a virtual system
     126among exceptions and used for exception matching.
     127
     128Ideally, the virtual system would have been part of \CFA before the work
    131129on exception handling began, but unfortunately it was not.
    132 Because of this only the features and framework needed for the EHM were
     130Therefore, only the features and framework needed for the EHM were
    133131designed and implemented. Other features were considered to ensure that
    134 the structure could accomidate other desirable features but they were not
     132the structure could accommodate other desirable features in the future but they were not
    135133implemented.
    136 The rest of this section will only discuss the finalized portion of the
    137 virtual system.
     134The rest of this section discusses the implemented subset of the
     135virtual-system design.
    138136
    139137The virtual system supports multiple ``trees" of types. Each tree is
    … …  
    145143% A type's ancestors are its parent and its parent's ancestors.
    146144% The root type has no ancestors.
    147 % A type's decendents are its children and its children's decendents.
     145% A type's decedents are its children and its children's decedents.
    148146
    149147Every virtual type also has a list of virtual members. Children inherit
    … …  
    151149It is important to note that these are virtual members, not virtual methods
    152150of 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 will be modified
     154Function pointers that take a pointer to the virtual type are 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 unique id and all the virtual members are combined
     160This 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.}
    163165
    164166Up until this point the virtual system is similar to ones found in
    165167object-orientated languages but this where \CFA diverges. Objects encapsulate a
    166168single set of behaviours in each type, universally across the entire program,
    167 and indeed all programs that use that type definition. In this sense the
     169and indeed all programs that use that type definition. In this sense, the
    168170types are ``closed" and cannot be altered.
    169171
    170 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
     172In \CFA, types do not encapsulate any behaviour. Traits are local and
     173types can begin to satisfy a trait, stop satisfying a trait or satisfy the same
    172174trait in a different way at any lexical location in the program.
    173 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
     175In this sense, they are ``open" as they can change at any time. This capability means it
     176is impossible to pick a single set of functions that represent the type's
    175177implementation across the program.
    176178
    177179\CFA side-steps this issue by not having a single virtual table for each
    178 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
     180type. A user can define virtual tables that are filled in at their
     181declaration and given a name. Anywhere that name is visible, even if
     182defined locally inside a function (although that means it does not have a
    181183static lifetime), it can be used.
    182 Specifically, a virtual type is ``bound" to a virtual table which
     184Specifically, a virtual type is ``bound" to a virtual table that
    183185sets the virtual members for that object. The virtual members can be accessed
    184186through the object.
    185187
     188\PAB{The above explanation is very good!}
     189
    186190While much of the virtual infrastructure is created, it is currently only used
    187191internally for exception handling. The only user-level feature is the virtual
    188 cast, which is the same as the \Cpp \code{C++}{dynamic_cast}.
     192cast
    189193\label{p:VirtualCast}
    190194\begin{cfa}
    191195(virtual TYPE)EXPRESSION
    192196\end{cfa}
     197which is the same as the \Cpp \code{C++}{dynamic_cast}.
    193198Note, the syntax and semantics matches a C-cast, rather than the function-like
    194199\Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be
    … …  
    212217\end{cfa}
    213218The trait is defined over two types, the exception type and the virtual table
    214 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
     219type. Each exception type should have a single virtual table type.
     220There are no actual assertions in this trait because currently the trait system
     221cannot express them (adding such assertions would be part of
    217222completing the virtual system). The imaginary assertions would probably come
    218223from a trait defined by the virtual system, and state that the exception type
    219 is a virtual type, is a decendent of @exception_t@ (the base exception type)
     224is a virtual type, is a descendent of @exception_t@ (the base exception type)
    220225and note its virtual table type.
    221226
    … …  
    236241};
    237242\end{cfa}
    238 Both traits ensure a pair of types are an exception type and its virtual table
     243Both traits ensure a pair of types are an exception type and its virtual table,
    239244and defines one of the two default handlers. The default handlers are used
    240245as fallbacks and are discussed in detail in \vref{s:ExceptionHandling}.
    … …  
    264269\section{Exception Handling}
    265270\label{s:ExceptionHandling}
    266 \CFA provides two kinds of exception handling: termination and resumption.
     271As stated, \CFA provides two kinds of exception handling: termination and resumption.
    267272These twin operations are the core of \CFA's exception handling mechanism.
    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.
     273This section covers the general patterns shared by the two operations and
     274then go on to cover the details of each individual operation.
    270275
    271276Both operations follow the same set of steps.
    272 Both start with the user preforming a raise on an exception.
    273 Then the exception propogates up the stack.
     277Both start with the user performing a raise on an exception.
     278Then the exception propagates up the stack.
    274279If a handler is found the exception is caught and the handler is run.
    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.
     280After that control returns to a point specific to the kind of exception.
     281If the search fails a default handler is run, and if it returns, control
     282continues after the raise. Note, the default handler may further change control flow rather than return.
    278283
    279284This general description covers what the two kinds have in common.
    280 Differences include how propogation is preformed, where exception continues
     285Differences include how propagation is performed, where exception continues
    281286after an exception is caught and handled and which default handler is run.
    282287
    283288\subsection{Termination}
    284289\label{s:Termination}
     290
    285291Termination handling is the familiar kind and used in most programming
    286292languages with exception handling.
    287 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
     293It is a dynamic, non-local goto. If the raised exception is matched and
     294handled, the stack is unwound and control (usually) continues in the function
    289295on the call stack that defined the handler.
    290296Termination is commonly used when an error has occurred and recovery is
    … …  
    301307termination exception is any type that satisfies the trait
    302308@is_termination_exception@ at the call site.
    303 Through \CFA's trait system the trait functions are implicity passed into the
     309Through \CFA's trait system, the trait functions are implicitly passed into the
    304310throw code and the EHM.
    305311A new @defaultTerminationHandler@ can be defined in any scope to
    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.
     312change the throw's behaviour (see below).
     313
     314The throw copies the provided exception into managed memory to ensure
     315the exception is not destroyed when the stack is unwound.
    310316It is the user's responsibility to ensure the original exception is cleaned
    311 up wheither the stack is unwound or not. Allocating it on the stack is
     317up whether the stack is unwound or not. Allocating it on the stack is
    312318usually sufficient.
    313319
    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,
     320Then propagation starts the search. \CFA uses a ``first match" rule so
     321matching is performed with the copied exception as the search continues.
     322It starts from the throwing function and proceeds towards the base of the stack,
    317323from callee to caller.
    318324At each stack frame, a check is made for resumption handlers defined by the
    … …  
    327333}
    328334\end{cfa}
    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.
     335When viewed on its own, a try statement simply executes the statements
     336in \snake{GUARDED_BLOCK} and when those are finished, the try statement finishes.
    331337
    332338However, while the guarded statements are being executed, including any
    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.
     339invoked functions, all the handlers in these statements are included on the search
     340path. Hence, if a termination exception is raised, the search includes the added handlers associated with the guarded block and those further up the
     341stack from the guarded block.
    336342
    337343Exception matching checks the handler in each catch clause in the order
    338 they appear, top to bottom. If the representation of the thrown exception type
     344they appear, top to bottom. If the representation of the raised exception type
    339345is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
    340 (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
     346(if provided) is bound to a pointer to the exception and the statements in
     347@HANDLER_BLOCK@$_i$ are executed.
     348If control reaches the end of the handler, the exception is
    343349freed and control continues after the try statement.
    344350
    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.
     351If no termination handler is found during the search, the default handler
     352(\defaultTerminationHandler) visible at the raise statement is called.
     353Through \CFA's trait system, the best match at the raise sight is used.
     354This function is run and is passed the copied exception. If the default
     355handler returns, control continues after the throw statement.
    350356
    351357There is a global @defaultTerminationHandler@ that is polymorphic over all
    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.
     358termination exception types. Since it is so general, a more specific handler can be
     359defined and is used for those types, effectively overriding the handler
     360for a particular exception type.
    355361The global default termination handler performs a cancellation
    356362(see \vref{s:Cancellation}) on the current stack with the copied exception.
    … …  
    362368just as old~\cite{Goodenough75} and is simpler in many ways.
    363369It is a dynamic, non-local function call. If the raised exception is
    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.
     370matched a closure is taken from up the stack and executed,
     371after which the raising function continues executing.
     372These are most often used when a potentially repairable error occurs, some handler is found on the stack to fix it, and
     373the raising function can continue with the correction.
     374Another common usage is dynamic event analysis, \eg logging, without disrupting control flow.
     375Note, 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}.
     378You may or may not want to mention it. You can still stick with \lstinline{catch} and \lstinline{throw/catchResume} in the thesis.}
    368379
    369380A resumption raise is started with the @throwResume@ statement:
    … …  
    376387@is_resumption_exception@ at the call site.
    377388The assertions from this trait are available to
    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.
     389the exception system, while handling the exception.
     390
     391Resumption does not need to copy the raised exception, as the stack is not unwound.
     392The exception and
     393any values on the stack remain in scope, while the resumption is handled.
    383394
    384395The EHM then begins propogation. The search starts from the raise in the
    385 resuming function and proceeds to the base of the stack, from callee to caller.
     396resuming function and proceeds towards the base of the stack, from callee to caller.
    386397At each stack frame, a check is made for resumption handlers defined by the
    387398@catchResume@ clauses of a @try@ statement.
    … …  
    398409Note that termination handlers and resumption handlers may be used together
    399410in a single try statement, intermixing @catch@ and @catchResume@ freely.
    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.
     411Each type of handler only interacts with exceptions from the matching
     412kind of raise.
     413When a try statement is executed, it simply executes the statements in the
     414@GUARDED_BLOCK@ and then returns.
    404415
    405416However, while the guarded statements are being executed, including any
    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.
     417invoked functions, all the handlers in these statements are included on the search
     418path. Hence, if a resumption exception is raised the search includes the added handlers associated with the guarded block and those further up the
     419stack from the guarded block.
    409420
    410421Exception matching checks the handler in each catch clause in the order
    411 they appear, top to bottom. If the representation of the thrown exception type
     422they appear, top to bottom. If the representation of the raised exception type
    412423is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
    413424(if provided) is bound to a pointer to the exception and the statements in
    … …  
    416427the raise statement that raised the handled exception.
    417428
    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
     429Like termination, if no resumption handler is found during the search, the default handler
     430(\defaultResumptionHandler) visible at the raise statement is called.
     431It uses the best match at the
     432raise sight according to \CFA's overloading rules. The default handler is
    421433passed the exception given to the throw. When the default handler finishes
    422434execution continues after the raise statement.
    423435
    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
     436There is a global \defaultResumptionHandler{} that is polymorphic over all
     437resumption exception types and preforms a termination throw on the exception.
     438The \defaultTerminationHandler{} can be
    428439customized by introducing a new or better match as well.
    429440
    430441\subsubsection{Resumption Marking}
    431442\label{s:ResumptionMarking}
     443
    432444A key difference between resumption and termination is that resumption does
    433445not unwind the stack. A side effect that is that when a handler is matched
    434 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
     446and run, its try block (the guarded statements) and every try statement
     447searched before it are still on the stack. Their existence can lead to the recursive
    436448resumption problem.
    437449
    … …  
    446458}
    447459\end{cfa}
    448 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
     460When this code is executed, the guarded @throwResume@ starts a
     461search and matchs the handler in the @catchResume@ clause. This
     462call is placed on the top of stack above the try-block. The second throw
     463searchs the same try block and puts call another instance of the
     464same handler on the stack leading to an infinite recursion.
     465
     466While this situation is trivial and easy to avoid, much more complex cycles
    455467can form with multiple handlers and different exception types.
    456468
    457 To prevent all of these cases we mark try statements on the stack.
     469To prevent all of these cases, the exception search marks the try statements it visits.
    458470A try statement is marked when a match check is preformed with it and an
    459 exception. The statement will be unmarked when the handling of that exception
     471exception. The statement is unmarked when the handling of that exception
    460472is completed or the search completes without finding a handler.
    461 While a try statement is marked its handlers are never matched, effectify
    462 skipping over it to the next try statement.
     473While a try statement is marked, its handlers are never matched, effectify
     474skipping over them to the next try statement.
    463475
    464476\begin{center}
    … …  
    467479
    468480These rules mirror what happens with termination.
    469 When a termination throw happens in a handler the search will not look at
     481When a termination throw happens in a handler, the search does not look at
    470482any handlers from the original throw to the original catch because that
    471 part of the stack has been unwound.
     483part of the stack is unwound.
    472484A resumption raise in the same situation wants to search the entire stack,
    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.
     485but with marking, the search does match exceptions for try statements at equivalent sections
     486that would have been unwound by termination.
     487
     488The symmetry between resumption termination is why this pattern is picked.
     489Other patterns, such as marking just the handlers that caught the exception, also work but
     490lack the symmetry, meaning there are more rules to remember.
    479491
    480492\section{Conditional Catch}
     493
    481494Both termination and resumption handler clauses can be given an additional
    482495condition to further control which exceptions they handle:
    … …  
    491504did not match.
    492505
    493 The condition matching allows finer matching by allowing the match to check
     506The condition matching allows finer matching to check
    494507more kinds of information than just the exception type.
    495508\begin{cfa}
    … …  
    506519// Can't handle a failure relating to f2 here.
    507520\end{cfa}
    508 In this example the file that experianced the IO error is used to decide
     521In this example, the file that experianced the IO error is used to decide
    509522which handler should be run, if any at all.
    510523
    … …  
    535548
    536549\subsection{Comparison with Reraising}
     550
    537551A more popular way to allow handlers to match in more detail is to reraise
    538 the exception after it has been caught if it could not be handled here.
     552the exception after it has been caught, if it could not be handled here.
    539553On the surface these two features seem interchangable.
    540554
    541 If we used @throw;@ to start a termination reraise then these two statements
    542 would have the same behaviour:
     555If @throw@ is used to start a termination reraise then these two statements
     556have the same behaviour:
    543557\begin{cfa}
    544558try {
    … …  
    560574}
    561575\end{cfa}
    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
     576However, if there are further handlers after this handler only the first is
     577check. For multiple handlers on a single try block that could handle the
     578same exception, the equivalent translations to conditional catch becomes more complex, resulting is multiple nested try blocks for all possible reraises.
     579So 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.
     582A conditional catch CAN happen with the stack unwound.
     583Roy talked about this issue in Section 2.3.3 here: \newline
     584\url{http://plg.uwaterloo.ca/theses/KrischerThesis.pdf}}
     585
     586Specifically for termination handling, a
    568587conditional catch happens before the stack is unwound, but a reraise happens
    569588afterwards. Normally this might only cause you to loose some debug
    570589information you could get from a stack trace (and that can be side stepped
    571590entirely by collecting information during the unwind). But for \CFA there is
    572 another issue, if the exception isn't handled the default handler should be
     591another issue, if the exception is not handled the default handler should be
    573592run at the site of the original raise.
    574593
    575 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
     594There are two problems with this: the site of the original raise does not
     595exist anymore and the default handler might not exist anymore. The site is
     596always removed as part of the unwinding, often with the entirety of the
    578597function it was in. The default handler could be a stack allocated nested
    579598function removed during the unwind.
    … …  
    586605\section{Finally Clauses}
    587606\label{s:FinallyClauses}
     607
    588608Finally clauses are used to preform unconditional clean-up when leaving a
    589609scope and are placed at the end of a try statement after any handler clauses:
    … …  
    598618The @FINALLY_BLOCK@ is executed when the try statement is removed from the
    599619stack, including when the @GUARDED_BLOCK@ finishes, any termination handler
    600 finishes or during an unwind.
     620finishes, or during an unwind.
    601621The only time the block is not executed is if the program is exited before
    602622the stack is unwound.
    … …  
    614634
    615635Not all languages with unwinding have finally clauses. Notably \Cpp does
    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.
     636without it as destructors with RAII serve a similar role. Although destructors and
     637finally clauses have overlapping usage cases, they have their own
     638specializations, like top-level functions and lambda functions with closures.
     639Destructors take more work if a number of unrelated, local variables without destructors or dynamically allocated variables must be passed for de-intialization.
     640Maintaining this destructor during local-block modification is a source of errors.
     641A finally clause places local de-intialization inline with direct access to all local variables.
    622642
    623643\section{Cancellation}
    … …  
    632652raise, this exception is not used in matching only to pass information about
    633653the cause of the cancellation.
    634 (This also means matching cannot fail so there is no default handler.)
     654(This restriction also means matching cannot fail so there is no default handler.)
    635655
    636656After @cancel_stack@ is called the exception is copied into the EHM's memory
    637657and the current stack is
    638 unwound. After that it depends one which stack is being cancelled.
     658unwound.
     659The result of a cancellation depends on the kind of stack that is being unwound.
    639660
    640661\paragraph{Main Stack}
    … …  
    643664After the main stack is unwound there is a program-level abort.
    644665
    645 There are two reasons for this. The first is that it obviously had to do this
     666There are two reasons for this semantics. The first is that it obviously had to do the abort
    646667in a sequential program as there is nothing else to notify and the simplicity
    647668of keeping the same behaviour in sequential and concurrent programs is good.
    648 Also, even in concurrent programs there is no stack that an innate connection
    649 to, so it would have be explicitly managed.
     669\PAB{I do not understand this sentence. $\Rightarrow$ Also, even in concurrent programs, there is no stack that an innate connection
     670to, so it would have be explicitly managed.}
    650671
    651672\paragraph{Thread Stack}
    652673A thread stack is created for a \CFA @thread@ object or object that satisfies
    653674the @is_thread@ trait.
    654 After a thread stack is unwound there exception is stored until another
     675After a thread stack is unwound, the exception is stored until another
    655676thread attempts to join with it. Then the exception @ThreadCancelled@,
    656677which stores a reference to the thread and to the exception passed to the
    657 cancellation, is reported from the join.
     678cancellation, is reported from the join to the joining thread.
    658679There is one difference between an explicit join (with the @join@ function)
    659680and an implicit join (from a destructor call). The explicit join takes the
    660681default handler (@defaultResumptionHandler@) from its calling context while
    661 the implicit join provides its own which does a program abort if the
     682the implicit join provides its own, which does a program abort if the
    662683@ThreadCancelled@ exception cannot be handled.
    663684
    664 Communication is done at join because a thread only has to have to points of
    665 communication with other threads: start and join.
     685\PAB{Communication can occur during the lifetime of a thread using shared variable and \lstinline{waitfor} statements.
     686Are 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
     687communication with other threads: start and join.}
    666688Since a thread must be running to perform a cancellation (and cannot be
    667689cancelled from another stack), the cancellation must be after start and
    668 before the join. So join is the one that we will use.
     690before the join, so join is use.
    669691
    670692% TODO: Find somewhere to discuss unwind collisions.
    … …  
    678700A coroutine stack is created for a @coroutine@ object or object that
    679701satisfies the @is_coroutine@ trait.
    680 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
     702After a coroutine stack is unwound, control returns to the @resume@ function
     703that most recently resumed it. The resume reports a
     704@CoroutineCancelled@ exception, which contains references to the cancelled
    683705coroutine and the exception used to cancel it.
    684 The resume function also takes the \defaultResumptionHandler{} from the
    685 caller's context and passes it to the internal report.
     706The @resume@ function also takes the \defaultResumptionHandler{} from the
     707caller's context and passes it to the internal cancellation.
    686708
    687709A coroutine knows of two other coroutines, its starter and its last resumer.
    688 The starter has a much more distant connection while the last resumer just
     710The starter has a much more distant connection, while the last resumer just
    689711(in terms of coroutine state) called resume on this coroutine, so the message
    690712is passed to the latter.

  • doc/theses/andrew_beach_MMath/intro.tex

    r553f8abe r4ed7946e  
    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
    38% Talk about Cforall and exceptions generally.
    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.
     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).
     12Exception handling provides alternative dynamic inter-function control flow.
    813There are two forms of exception handling covered in this thesis:
    914termination, which acts as a multi-level return,
    1015and resumption, which is a dynamic function call.
    11 This seperation is uncommon because termination exception handling is so
    12 much more common that it is often assumed.
     16Note, termination exception handling is so common it is often assumed to be the only form.
     17Lesser know derivations of inter-function control flow are continuation passing in Lisp~\cite{CommonLisp}.
    1318
    1419Termination exception handling allows control to return to any previous
    … …  
    3136
    3237% Overview of exceptions in Cforall.
    33 This work describes the design and implementation of the \CFA EHM.
     38
     39\PAB{You need section titles here. Don't take them out.}
     40
     41\section{Thesis Overview}
     42
     43This thesis goes over the design and implementation of the exception handling
     44mechanism (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.
    3447The \CFA EHM implements all of the common exception features (or an
    3548equivalent) found in most other EHMs and adds some features of its own.
    … …  
    5265
    5366% A note that yes, that was a very fast overview.
    54 All the design and implementation of all of \CFA's EHM's features are
     67The design and implementation of all of \CFA's EHM's features are
    5568described in detail throughout this thesis, whether they are a common feature
    5669or one unique to \CFA.
    5770
    5871% The current state of the project and what it contributes.
    59 All of these features have been added to the \CFA implemenation, along with
     72All of these features have been implemented in \CFA, along with
    6073a suite of test cases as part of this project.
    6174The implementation techniques are generally applicable in other programming
    … …  
    6376Some parts of the EHM use other features unique to \CFA and these would be
    6477harder to replicate in other programming languages.
     78
     79\section{Background}
    6580
    6681% Talk about other programming languages.
    … …  
    7085Exceptions also can replace return codes and return unions.
    7186In functional languages will also sometimes fold exceptions into monads.
     87
     88\PAB{You must demonstrate knowledge of background material here.
     89It should be at least a full page.}
     90
     91\section{Contributions}
    7292
    7393The contributions of this work are:
Note: See TracChangeset for help on using the changeset viewer.