Changeset 59f3f61 for doc


Ignore:
Timestamp:
Apr 20, 2021, 4:34:59 PM (3 months ago)
Author:
Andrew Beach <ajbeach@…>
Branches:
arm-eh, jacob/cs343-translation, master
Children:
0583b47b, 6c5d92f
Parents:
d2fadeb (diff), 6a8208c (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'andrew-mmath' into 'master', collecting my responses to Peter's last updates.

Location:
doc/theses/andrew_beach_MMath
Files:
4 deleted
3 edited
2 moved

Legend:

Unmodified
Added
Removed
  • doc/theses/andrew_beach_MMath/Makefile

    rd2fadeb r59f3f61  
    11### Makefile for Andrew Beach's Masters Thesis
    22
    3 DOC = uw-ethesis.pdf
    4 BASE = ${DOC:%.pdf=%} # remove suffix
    5 # directory for latex clutter files
    6 BUILD = build
    7 TEXSRC = $(wildcard *.tex)
    8 FIGSRC = $(wildcard *.fig)
    9 BIBSRC = $(wildcard *.bib)
    10 STYSRC = $(wildcard *.sty)
    11 CLSSRC = $(wildcard *.cls)
    12 TEXLIB = .:../../LaTeXmacros:${BUILD}: # common latex macros
    13 BIBLIB = .:../../bibliography # common citation repository
     3DOC=uw-ethesis.pdf
     4BUILD=out
     5TEXSRC=$(wildcard *.tex)
     6FIGSRC=$(wildcard *.fig)
     7BIBSRC=$(wildcard *.bib)
     8STYSRC=$(wildcard *.sty)
     9CLSSRC=$(wildcard *.cls)
     10TEXLIB= .:../../LaTeXmacros:${BUILD}:
     11BIBLIB= .:../../bibliography
    1412
    15 MAKEFLAGS = --no-print-directory # --silent
    16 VPATH = ${BUILD}
     13# Since tex programs like to add their own file extensions:
     14BASE= ${DOC:%.pdf=%}
     15
     16RAWSRC=${TEXSRC} ${BIBSRC} ${STYSRC} ${CLSSRC}
     17FIGTEX=${FIGSRC:%.fig=${BUILD}/%.tex}
    1718
    1819### Special Rules:
    1920
    2021.PHONY: all clean deepclean
    21 .PRECIOUS: %.dvi %.ps # do not delete intermediate files
    2222
    2323### Commands:
    24 LATEX = TEXINPUTS=${TEXLIB} && export TEXINPUTS && latex -halt-on-error -output-directory=${BUILD}
    25 BIBTEX = BIBINPUTS=${BIBLIB} bibtex
    26 GLOSSARY = INDEXSTYLE=${BUILD} makeglossaries-lite
     24LATEX=TEXINPUTS=${TEXLIB} latex -halt-on-error -output-directory=${BUILD}
     25BIBTEX=BIBINPUTS=${BIBLIB} bibtex
     26GLOSSARY=INDEXSTYLE=${BUILD} makeglossaries-lite
    2727
    28 ### Rules and Recipes:
     28### Rules and Recipies:
    2929
    3030all: ${DOC}
    3131
    32 ${BUILD}/%.dvi: ${TEXSRC} ${FIGSRC:.fig=.tex} ${BIBSRC} ${STYSRC} ${CLSSRC} Makefile | ${BUILD}
     32# The main rule, it does all the tex/latex processing.
     33${BUILD}/${BASE}.dvi: ${RAWSRC} ${FIGTEX} Makefile | ${BUILD}
    3334        ${LATEX} ${BASE}
    3435        ${BIBTEX} ${BUILD}/${BASE}
     
    3738        ${LATEX} ${BASE}
    3839
     40# Convert xfig output to tex. (Generates \special declarations.)
     41${FIGTEX}: ${BUILD}/%.tex: %.fig | ${BUILD}
     42        fig2dev -L eepic $< > $@
     43
     44# Step through dvi & postscript to handle xfig specials.
     45%.pdf : ${BUILD}/%.dvi
     46        dvipdf $^ $@
     47
    3948${BUILD}:
    4049        mkdir $@
    4150
    42 %.pdf : ${BUILD}/%.ps | ${BUILD}
    43         ps2pdf $<
    44 
    45 %.ps : %.dvi | ${BUILD}
    46         dvips $< -o $@
    47 
    48 %.tex : %.fig | ${BUILD}
    49         fig2dev -L eepic $< > ${BUILD}/$@
    50 
    51 %.ps : %.fig | ${BUILD}
    52         fig2dev -L ps $< > ${BUILD}/$@
    53 
    54 %.pstex : %.fig | ${BUILD}
    55         fig2dev -L pstex $< > ${BUILD}/$@
    56         fig2dev -L pstex_t -p ${BUILD}/$@ $< > ${BUILD}/$@_t
    57 
    5851clean:
    59         @rm -frv ${BUILD} *.fig.bak
     52        -@rm -rv ${BUILD}
    6053
    6154deepclean: clean
    62         -@rm -fv ${DOC}
     55        -@rm -v ${DOC}
  • doc/theses/andrew_beach_MMath/features.tex

    rd2fadeb r59f3f61  
    33This chapter covers the design and user interface of the \CFA
    44exception-handling mechanism (EHM). % or exception system.
    5 While an EHM is free to add many features,
    6 the following overview covers the basic features that all EHMs use, but it is not an
    7 exhaustive list of everything an EHM can do.
     5
     6We will begin with an overview of EHMs in general. It is not a strict
     7definition of all EHMs nor an exaustive list of all possible features.
     8However it does cover the most common structure and features found in them.
    89
    910% We should cover what is an exception handling mechanism and what is an
     
    1415These terms are sometimes also known as throw and catch but this work uses
    1516throw/catch as a particular kind of raise/handle.
    16 These are the two parts a programmer writes and so
    17 are the only two pieces of the EHM that have language syntax.
     17These are the two parts that the user will write themselves and may
     18be the only two pieces of the EHM that have any syntax in the language.
    1819
    1920\subparagraph{Raise}
    20 The raise is the starting point for exception handling and usually how \PAB{This sentence is cut off.}
    21 Some well known examples include the @throw@ statement of \Cpp and Java and
    22 the \lstinline[language=Python]{raise} statement from Python.
    23 
    24 For this overview, a raise starts the handling of an
    25 exception, which is called \newterm{raising} an exception. This simple description is sufficient
    26 for the overview.
     21The raise is the starting point for exception handling. It marks the beginning
     22of exception handling by \newterm{raising} an excepion, which passes it to
     23the EHM.
     24
     25Some well known examples include the @throw@ statements of \Cpp and Java and
     26the \codePy{raise} statement from Python. In real systems a raise may preform
     27some other work (such as memory management) but for the purposes of this
     28overview that can be ignored.
    2729
    2830\subparagraph{Handle}
    29 The purpose of raising an exception is to run user code to address (handle) the
    30 issue found at the raise point.
    31 The @try@ statement of \Cpp illustrates a common approach for specifying multiple handlers.
    32 A handler has three common features: the scope in which it applies, an
    33 exception label that describes what exceptions it can handle, and code to run
    34 that deals with the raised issue.
    35 Each handler can handle exceptions raised in the region matching its
    36 exception label. For multiple matches, different EHMs have different rules for matching an exception to a handler label,
    37 such as ``best match" or ``first found".
     31The purpose of most exception operations is to run some user code to handle
     32that exception. This code is given, with some other information, in a handler.
     33
     34A handler has three common features: the previously mentioned user code, a
     35region of code they cover and an exception label/condition that matches
     36certain exceptions.
     37Only raises inside the covered region and raising exceptions that match the
     38label can be handled by a given handler.
     39Different EHMs will have different rules to pick a handler
     40if multipe handlers could be used such as ``best match" or ``first found".
     41
     42The @try@ statements of \Cpp, Java and Python are common examples. All three
     43also show another common feature of handlers, they are grouped by the covered
     44region.
    3845
    3946\paragraph{Propagation}
    40 After an exception is raised, comes the most complex step for the
    41 EHM: finding and setting up the handler. This propagation of exception from raise to handler can be broken up into three
    42 different tasks: searching, matching, and
    43 installing the handler so it can execute.
     47After an exception is raised comes what is usually the biggest step for the
     48EHM: finding and setting up the handler. The propogation from raise to
     49handler can be broken up into three different tasks: searching for a handler,
     50matching against the handler and installing the handler.
    4451
    4552\subparagraph{Searching}
    46 The EHM searches for possible handlers that can be used to handle
    47 the exception. Searching is usually independent of the exception that is
    48 thrown and instead depends on the call stack: current function, its caller
    49 and repeating down the stack.
     53The EHM begins by searching for handlers that might be used to handle
     54the exception. Searching is usually independent of the exception that was
     55thrown as it looks for handlers that have the raise site in their covered
     56region.
     57This includes handlers in the current function, as well as any in callers
     58on the stack that have the function call in their covered region.
    5059
    5160\subparagraph{Matching}
    52 For each handler found, it compares the raised exception with the handler label to see which one is the
    53 best match, and hence, which one should be used to handle the exception.
    54 In languages where the best match is the first match, these two steps are often
    55 intertwined, \ie a match check is performed immediately after the search finds
     61Each handler found has to be matched with the raised exception. The exception
     62label defines a condition that be use used with exception and decides if
     63there is a match or not.
     64
     65In languages where the first match is used this step is intertwined with
     66searching, a match check is preformed immediately after the search finds
    5667a possible handler.
    5768
    5869\subparagraph{Installing}
    59 After a handler is chosen, it must be made ready to run.
    60 This step varies widely to fit with the rest of the
    61 design of the EHM. The installation step might be trivial or it can be
     70After a handler is chosen it must be made ready to run.
     71The implementation can vary widely to fit with the rest of the
     72design of the EHM. The installation step might be trivial or it could be
    6273the most expensive step in handling an exception. The latter tends to be the
    6374case when stack unwinding is involved.
    64 An alternate action occurs if no appropriate handler is found, then some implicit action
    65 is performed. This step is only required with unchecked
    66 exceptions as checked exceptions (Java) promise a handler is always found. The implicit action
    67 also installs a handler but it is a default handle that may be
    68 installed differently.
     75
     76If a matching handler is not guarantied to be found the EHM will need a
     77different course of action here in the cases where no handler matches.
     78This is only required with unchecked exceptions as checked exceptions
     79(such as in Java) can make than guaranty.
     80This different action can also be installing a handler but it is usually an
     81implicat and much more general one.
    6982
    7083\subparagraph{Hierarchy}
    71 Some EHM (\CFA, Java) organize exceptions in a hierarchical structure.
    72 This strategy is borrowed from object-orientated languages where the
     84A common way to organize exceptions is in a hierarchical structure.
     85This is especially true in object-orientated languages where the
    7386exception hierarchy is a natural extension of the object hierarchy.
    7487
    7588Consider the following hierarchy of exceptions:
    7689\begin{center}
    77 \input{exceptionHierarchy}
     90\input{exception-hierarchy}
    7891\end{center}
     92
    7993A handler labelled with any given exception can handle exceptions of that
    8094type or any child type of that exception. The root of the exception hierarchy
    81 (here \lstinline[language=C++]{exception}) acts as a catch-all, leaf types catch single types
     95(here \codeC{exception}) acts as a catch-all, leaf types catch single types
    8296and the exceptions in the middle can be used to catch different groups of
    8397related exceptions.
    8498
    8599This system has some notable advantages, such as multiple levels of grouping,
    86 the ability for libraries to add new exception types, and the isolation
    87 between different sub-hierarchies. This capability had to be adapted for \CFA, which is a
    88 non-object-orientated language.
     100the ability for libraries to add new exception types and the isolation
     101between different sub-hierarchies.
     102This design is used in \CFA even though it is not a object-orientated
     103language using different tools to create the hierarchy.
    89104
    90105% Could I cite the rational for the Python IO exception rework?
    91106
    92107\paragraph{Completion}
    93 After the handler has returned, the entire exception operation has to complete
    94 and continue executing somewhere. This step is usually simple,
     108After the handler has finished the entire exception operation has to complete
     109and continue executing somewhere else. This step is usually simple,
    95110both logically and in its implementation, as the installation of the handler
    96 usually does the preparation.
    97 The EHM can return control to different places,
    98 where the most common are after the handler definition or after the raise.
     111is usually set up to do most of the work.
     112
     113The EHM can return control to many different places,
     114the most common are after the handler definition and after the raise.
    99115
    100116\paragraph{Communication}
    101 For effective exception handling, additional information is usually passed from the raise,
    102 where this basic model only communicates the exception's identity. A common
    103 methods for communication is putting fields into an exception and
    104 allowing a handler to access these fields via an exception instance in the handler's scope.
     117For effective exception handling, additional information is usually passed
     118from the raise to the handler.
     119So far only communication of the exceptions' identity has been covered.
     120A common method is putting fields into the exception instance and giving the
     121handler access to them.
    105122
    106123\section{Virtuals}
    107 Virtual types and casts are not part of an EHM nor are they
    108 required for an EHM. But as pointed out, an object-oriented-style hierarchy is an
    109 excellent way of organizing exceptions. Hence, a minimal virtual system has been added
    110 to \CFA to support hierarchical exceptions.
     124Virtual types and casts are not part of \CFA's EHM nor are they required for
     125any EHM. But \CFA uses a hierarchial system of exceptions and this feature
     126is leveraged to create that.
     127
     128% Maybe talk about why the virtual system is so minimal.
     129% Created for but not a part of the exception system.
    111130
    112131The virtual system supports multiple ``trees" of types. Each tree is
    113132a simple hierarchy with a single root type. Each type in a tree has exactly
    114 one parent -- except for the root type with zero parents -- and any
     133one parent -- except for the root type which has zero parents -- and any
    115134number of children.
    116135Any type that belongs to any of these trees is called a virtual type.
     
    118137% A type's ancestors are its parent and its parent's ancestors.
    119138% The root type has no ancestors.
    120 % A type's descendents are its children and its children's descendents.
    121 
    122 Every virtual type has a list of virtual members. Children inherit
    123 their parent's virtual members but may add new members to it.
    124 It is important to note that these are virtual members, not virtual methods of an object type.
    125 However, as \CFA has function pointers, they can be used to mimic virtual
    126 methods.
     139% A type's decendents are its children and its children's decendents.
     140
     141Every virtual type also has a list of virtual members. Children inherit
     142their parent's list of virtual members but may add new members to it.
     143It is important to note that these are virtual members, not virtual methods
     144of object-orientated programming, and can be of any type.
     145However, since \CFA has function pointers and they are allowed, virtual
     146members can be used to mimic virtual methods.
    127147
    128148Each virtual type has a unique id.
    129 The unique id for the virtual type and all its virtual members are combined
    130 into a virtual-table type. Each virtual type has a pointer to a virtual table
     149This unique id and all the virtual members are combined
     150into a virtual table type. Each virtual type has a pointer to a virtual table
    131151as a hidden field.
    132152
    133 Up to this point, a virtual system is similar to ones found in object-oriented
    134 languages but this is where \CFA diverges. Objects encapsulate a
     153Up until this point the virtual system is similar to ones found in
     154object-orientated languages but this where \CFA diverges. Objects encapsulate a
    135155single set of behaviours in each type, universally across the entire program,
    136 and indeed all programs that use that type definition. In this sense, the
     156and indeed all programs that use that type definition. In this sense the
    137157types are ``closed" and cannot be altered.
    138 However, \CFA types do not encapsulate any behaviour. Instead, traits are used and
    139 types can satisfy a trait, stop satisfying a trait, or satisfy the same
    140 trait in a different way depending on the lexical context. In this sense, the types are
    141 ``open" as their behaviour can change in different scopes. This capability means it is impossible to pick
    142 a single set of functions that represent the type's virtual members.
    143 
    144 Hence, \CFA does not have a single virtual table for a type. A user can define different virtual tables,
    145 which are filled in at their declaration and given a name.
    146 That name is used as the virtual table, even if it is defined locally
    147 inside a function, although lifetime issues must be considered.
    148 Specifically, an object of a virtual type is ``bound" to a virtual table instance, which
     158
     159In \CFA types do not encapsulate any behaviour. Traits are local and
     160types can begin to statify a trait, stop satifying a trait or satify the same
     161trait in a different way at any lexical location in the program.
     162In this sense they are ``open" as they can change at any time. This means it
     163is implossible to pick a single set of functions that repersent the type's
     164implementation across the program.
     165
     166\CFA side-steps this issue by not having a single virtual table for each
     167type. A user can define virtual tables which are filled in at their
     168declaration and given a name. Anywhere that name is visible, even if it was
     169defined locally inside a function (although that means it will not have a
     170static lifetime), it can be used.
     171Specifically, a virtual type is ``bound" to a virtual table which
    149172sets the virtual members for that object. The virtual members can be accessed
    150173through the object.
     
    160183\Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be
    161184a pointer to a virtual type.
    162 The cast dynamically checks if the @EXPRESSION@ type is the same or a subtype
     185The cast dynamically checks if the @EXPRESSION@ type is the same or a sub-type
    163186of @TYPE@, and if true, returns a pointer to the
    164187@EXPRESSION@ object, otherwise it returns @0p@ (null pointer).
     
    178201\end{cfa}
    179202The trait is defined over two types, the exception type and the virtual table
    180 type. These type should have a one-to-one relationship: each exception type has only one virtual
     203type. This should be one-to-one: each exception type has only one virtual
    181204table type and vice versa. The only assertion in the trait is
    182205@get_exception_vtable@, which takes a pointer of the exception type and
    183 returns a reference to the virtual-table type-instance.
    184 
     206returns a reference to the virtual table type instance.
     207
     208% TODO: This section, and all references to get_exception_vtable, are
     209% out-of-data. Perhaps wait until the update is finished before rewriting it.
    185210The function @get_exception_vtable@ is actually a constant function.
    186 Regardless of the value passed in (including the null pointer) it
    187 returns a reference to the virtual-table instance for that type.
    188 The reason it is a function instead of a constant is to make type
    189 annotations easier to write using the exception type rather than the
    190 virtual-table type, which usually has a mangled name because it is an internal component of the EHM.
     211Regardless of the value passed in (including the null pointer) it should
     212return a reference to the virtual table instance for that type.
     213The reason it is a function instead of a constant is that it make type
     214annotations easier to write as you can use the exception type instead of the
     215virtual table type; which usually has a mangled name.
    191216% Also \CFA's trait system handles functions better than constants and doing
    192217% it this way reduce the amount of boiler plate we need.
     
    194219% I did have a note about how it is the programmer's responsibility to make
    195220% sure the function is implemented correctly. But this is true of every
    196 % similar system I know of (except Ada's I guess) so I took it out.
    197 
    198 There are two more exception traits defined as follows:
     221% similar system I know of (except Agda's I guess) so I took it out.
     222
     223There are two more traits for exceptions defined as follows:
    199224\begin{cfa}
    200225trait is_termination_exception(
     
    208233};
    209234\end{cfa}
    210 These traits ensure a given type and virtual type are an
    211 exception type and defines one of the two default handlers. The default handlers
    212 are used in the main exception-handling operations and discussed in detail in \VRef{s:ExceptionHandling}.
    213 
    214 However, all three of these traits are tricky to use directly.
     235Both traits ensure a pair of types are an exception type and its virtual table
     236and defines one of the two default handlers. The default handlers are used
     237as fallbacks and are discussed in detail in \VRef{s:ExceptionHandling}.
     238
     239However, all three of these traits can be tricky to use directly.
    215240While there is a bit of repetition required,
    216 the largest issue is that the virtual-table type is mangled and not in a user
    217 facing way. So three macros are provided to wrap these traits
    218 to simplify referring to the names:
     241the largest issue is that the virtual table type is mangled and not in a user
     242facing way. So these three macros are provided to wrap these traits to
     243simplify referring to the names:
    219244@IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@.
    220245
    221 These macros take one or two arguments. The first argument is the name of the
    222 exception type. The macro passes the unmangled and mangled form to the trait.
     246All three take one or two arguments. The first argument is the name of the
     247exception type. The macro passes its unmangled and mangled form to the trait.
    223248The second (optional) argument is a parenthesized list of polymorphic
    224249arguments. This argument is only used with polymorphic exceptions and the
    225 list is passed to both types.
    226 In the current set-up, the base name and the polymorphic arguments have to
    227 match so these macros can be used without losing flexibility.
     250list is be passed to both types.
     251In the current set-up, the two types always have the same polymorphic
     252arguments so these macros can be used without losing flexibility.
    228253
    229254For example consider a function that is polymorphic over types that have a
    230255defined arithmetic exception:
    231256\begin{cfa}
    232 forall(Num | @IS_EXCEPTION(Arithmetic, Num)@)
     257forall(Num | IS_EXCEPTION(Arithmetic, (Num)))
    233258void some_math_function(Num & left, Num & right);
    234259\end{cfa}
    235 where the function may raise exception @Arithmetic@ or any of its decedents.
    236260
    237261\section{Exception Handling}
    238262\label{s:ExceptionHandling}
    239263\CFA provides two kinds of exception handling: termination and resumption.
    240 These twin mechanisms are the core of the \CFA EHM and
    241 multiple features are provided to support them.
    242 This section covers the general patterns shared by the two kinds of exceptions and
    243 then covers the individual detail operations.
    244 
    245 Both mechanisms follow the same set of steps to do their operations. Both
    246 start with the user performing an exception raise.
    247 Then there is the handler search. If one is found, than the exception
    248 is caught and the handler is run. When the handler returns, control returns to an
    249 location appropriate for each kind of exception.
    250 
    251 \begin{sloppypar}
    252 If the search fails, an appropriate default handler, @defaultTermiationHandler@
    253 or @defaultResumptionHandler@, is run and  control returns to the
    254 appropriate location.
    255 \end{sloppypar}
     264These twin operations are the core of \CFA's exception handling mechanism.
     265This section will cover the general patterns shared by the two operations and
     266then go on to cover the details each individual operation.
     267
     268Both operations follow the same set of steps.
     269Both start with the user preforming a raise on an exception.
     270Then the exception propogates up the stack.
     271If a handler is found the exception is caught and the handler is run.
     272After that control returns to normal execution.
     273If the search fails a default handler is run and then control
     274returns to normal execution after the raise.
     275
     276This general description covers what the two kinds have in common.
     277Differences include how propogation is preformed, where exception continues
     278after an exception is caught and handled and which default handler is run.
    256279
    257280\subsection{Termination}
    258281\label{s:Termination}
    259 Termination handling is familiar and used in most programming
     282Termination handling is the familiar kind and used in most programming
    260283languages with exception handling.
    261 It is a dynamic, non-local goto. The raise starts searching, and if matched and handled, the stack is
    262 unwound and control (usually) continues in the function on
    263 the call stack containing the handler. Terminate is commonly used for an error where recovery
    264 is impossible in the function performing the raise.
     284It is dynamic, non-local goto. If the raised exception is matched and
     285handled the stack is unwound and control will (usually) continue the function
     286on the call stack that defined the handler.
     287Termination is commonly used when an error has occurred and recovery is
     288impossible locally.
    265289
    266290% (usually) Control can continue in the current function but then a different
     
    272296\end{cfa}
    273297The expression must return a reference to a termination exception, where the
    274 termination exception is any type that satisfies trait
    275 @is_termination_exception@ at the call site.  Through \CFA's trait system, the
    276 trait functions are implicitly passed into the hidden throw code and available
    277 to the exception system while handling the exception. A new
    278 @defaultTerminationHandler@ can be defined in any scope to change the throw's
    279 unhandled behaviour (see below).
    280 
    281 The throw must copy the provided exception into managed memory because the stack is unwounded.
    282 The lifetime of the exception copy is managed by the exception runtime.
    283 It is the user's responsibility to ensure the original exception is cleaned up, where allocating it on the unwound stack is sufficient.
    284 
    285 The exception search walks the stack matching with the copied exception.
     298termination exception is any type that satisfies the trait
     299@is_termination_exception@ at the call site.
     300Through \CFA's trait system the trait functions are implicity passed into the
     301throw code and the EHM.
     302A new @defaultTerminationHandler@ can be defined in any scope to
     303change the throw's behavior (see below).
     304
     305The throw will copy the provided exception into managed memory to ensure
     306the exception is not destroyed if the stack is unwound.
     307It is the user's responsibility to ensure the original exception is cleaned
     308up wheither the stack is unwound or not. Allocating it on the stack is
     309usually sufficient.
     310
     311Then propogation starts with the search. \CFA uses a ``first match" rule so
     312matching is preformed with the copied exception as the search continues.
    286313It starts from the throwing function and proceeds to the base of the stack,
    287314from callee to caller.
    288 At each stack frame, a check is made for termination handlers defined by the
     315At each stack frame, a check is made for resumption handlers defined by the
    289316@catch@ clauses of a @try@ statement.
    290317\begin{cfa}
    291318try {
    292319        GUARDED_BLOCK
    293 } catch (EXCEPTION_TYPE$\(_1\)$ [* NAME$\(_1\)$]) {
     320} catch (EXCEPTION_TYPE$\(_1\)$ * [NAME$\(_1\)$]) {
    294321        HANDLER_BLOCK$\(_1\)$
    295 } catch (EXCEPTION_TYPE$\(_2\)$ [* NAME$\(_2\)$]) {
     322} catch (EXCEPTION_TYPE$\(_2\)$ * [NAME$\(_2\)$]) {
    296323        HANDLER_BLOCK$\(_2\)$
    297324}
    298325\end{cfa}
    299 When viewed on its own, a @try@ statement with @catch@ clauses simply executes the statements in
    300 the @GUARDED_BLOCK@, and when those are finished, the try statement finishes.
    301 
    302 However, while the guarded statements are being executed, including any invoked
    303 functions, a termination exception may be thrown. If that exception is not handled by a try
    304 statement further up the stack, the handlers following the try block are now
    305 searched for a matching termination exception-type from top to bottom.
    306 
    307 Exception matching checks each @catch@ clasue from top to bottom, if the representation of the thrown exception-type is
    308 the same or a descendant type of the exception types in the @catch@ clauses. If
    309 it is the same or a descendant of @EXCEPTION_TYPE@$_i$, then the optional @NAME@$_i$ is
     326When viewed on its own, a try statement will simply execute the statements
     327in @GUARDED_BLOCK@ and when those are finished the try statement finishes.
     328
     329However, while the guarded statements are being executed, including any
     330invoked functions, all the handlers in the statement are now on the search
     331path. If a termination exception is thrown and not handled further up the
     332stack they will be matched against the exception.
     333
     334Exception matching checks the handler in each catch clause in the order
     335they appear, top to bottom. If the representation of the thrown exception type
     336is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
     337(if provided) is
    310338bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
    311339are executed. If control reaches the end of the handler, the exception is
    312 freed and control continues after the @try@ statement.
    313 
    314 If no termination handler is found during the search, the default termination
    315 handler visible at the raise is called.  Through \CFA's trait-system the best
    316 default-handler match at the throw sight is used.  This function is
    317 passed the copied exception given to the raise. After the default handler is
    318 run, control continues after the @throw@ statement.
    319 
    320 There is a global @defaultTerminationHandler@ function that that is polymorphic
    321 over all exception types allowing new default handlers to be defined for
    322 different exception types and so different exception types can have different
    323 default handlers.  The global default termination-handler performs a
    324 cancellation \see{\VRef{s:Cancellation}} on the current stack with the copied
    325 exception.
     340freed and control continues after the try statement.
     341
     342If no termination handler is found during the search then the default handler
     343(@defaultTerminationHandler@) is run.
     344Through \CFA's trait system the best match at the throw sight will be used.
     345This function is run and is passed the copied exception. After the default
     346handler is run control continues after the throw statement.
     347
     348There is a global @defaultTerminationHandler@ that is polymorphic over all
     349exception types. Since it is so general a more specific handler can be
     350defined and will be used for those types, effectively overriding the handler
     351for particular exception type.
     352The global default termination handler performs a cancellation
     353\see{\VRef{s:Cancellation}} on the current stack with the copied exception.
    326354
    327355\subsection{Resumption}
    328356\label{s:Resumption}
    329 Resumption exception-handling is a less common counterpart to termination but is
    330 just as old~\cite{Goodenough75} and is simpler to understand.
    331 It is a dynamic, non-local function call (like Lisp). If the throw is successful, a
    332 closure is taken from up the stack and executed, after which the throwing
    333 function continues executing.
    334 Resumption is used when an error occurred, and if the error is repaired,
     357
     358Resumption exception handling is less common than termination but is
     359just as old~\cite{Goodenough75} and is simpler in many ways.
     360It is a dynamic, non-local function call. If the raised exception is
     361matched a closure will be taken from up the stack and executed,
     362after which the raising function will continue executing.
     363These are most often used when an error occurred and if the error is repaired
    335364then the function can continue.
    336365
    337 An alternative approach is explicitly passing fixup functions with local
    338 closures up the stack to be called when an error occurs. However, fixup
    339 functions significantly expand the parameters list of functions, even when the
    340 fixup function is not used by a function but must be passed to other called
    341 functions.
    342 
    343366A resumption raise is started with the @throwResume@ statement:
    344367\begin{cfa}
    345368throwResume EXPRESSION;
    346369\end{cfa}
    347 Like termination, the expression must return a reference to a resumption
    348 exception, where the resumption exception is any type that satisfies the trait
    349 @is_termination_exception@ at the call site.
    350 The assertions for this trait are available to
     370It works much the same way as the termination throw.
     371The expression must return a reference to a resumption exception,
     372where the resumption exception is any type that satisfies the trait
     373@is_resumption_exception@ at the call site.
     374The assertions from this trait are available to
    351375the exception system while handling the exception.
    352376
    353 At runtime, no exception copy is made, as the stack is not unwound. Hence, the exception and
    354 any values on the stack remain in scope while the resumption is handled.
    355 
    356 The exception searches walks the stack matching with the provided exception.
    357 It starts from the resuming function and proceeds to the base of the stack,
    358 from callee to caller.
     377At run-time, no exception copy is made.
     378As the stack is not unwound the exception and
     379any values on the stack will remain in scope while the resumption is handled.
     380
     381The EHM then begins propogation. The search starts from the raise in the
     382resuming function and proceeds to the base of the stack, from callee to caller.
    359383At each stack frame, a check is made for resumption handlers defined by the
    360384@catchResume@ clauses of a @try@ statement.
     
    362386try {
    363387        GUARDED_BLOCK
    364 } catchResume (EXCEPTION_TYPE$\(_1\)$ [* NAME$\(_1\)$]) {
     388} catchResume (EXCEPTION_TYPE$\(_1\)$ * [NAME$\(_1\)$]) {
    365389        HANDLER_BLOCK$\(_1\)$
    366 } catchResume (EXCEPTION_TYPE$\(_2\)$ [* NAME$\(_2\)$]) {
     390} catchResume (EXCEPTION_TYPE$\(_2\)$ * [NAME$\(_2\)$]) {
    367391        HANDLER_BLOCK$\(_2\)$
    368392}
    369393\end{cfa}
    370 Termination and resumption handlers may be intermixed in a @try@
    371 statement but the kind of throw must match with kind of handler for it to be
    372 considered as a possible match.
    373 Like termination, when viewed on its own, a @try@ statement with
    374 @catchResume@ clauses simply executes the statements in the @GUARDED_BLOCK@,
    375 and when those are finished, the try statement finishes.
    376 
    377 However, while the guarded statements are being executed, including any invoked
    378 functions, a resumption exception may be thrown. If that exception is not handled by a try
    379 statement further up the stack, the handlers following the try block are now
    380 searched for a matching resumption exception-type from top to bottom.
    381 
    382 Like termination, exception matching checks each @catch@ clasue from top to bottom, if the representation of the thrown exception-type is
    383 the same or a descendant type of the exception types in the @catchResume@ clauses. If
    384 it is the same or a descendant of @EXCEPTION_TYPE@$_i$, then the optional @NAME@$_i$ is
    385 bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
    386 are executed. If control reaches the end of the handler, the exception is
    387 freed and control continues after the @throwResume@ statement.
    388 
    389 Like termination, if no resumption handler is found during the search, the
    390 default resumption handler visible at the raise is called, which is the best
    391 match at the according to \CFA's overloading rules. This function is passed the
    392 exception given to the raise. After the default handler is run, execution
    393 continues after the @throwResume@ statement.
    394 
    395 There is a global @defaultResumptionHandler@ that is polymorphic over all
    396 resumption and preforms a termination throw on the exception.
    397 The @defaultTerminationHandler@ for that throw is matched at the original
    398 throw statement (the resumption @throwResume@) and it can be customized by
     394% I wonder if there would be some good central place for this.
     395Note that termination handlers and resumption handlers may be used together
     396in a single try statement, intermixing @catch@ and @catchResume@ freely.
     397Each type of handler will only interact with exceptions from the matching
     398type of raise.
     399When a try statement is executed it simply executes the statements in the
     400@GUARDED_BLOCK@ and then finishes.
     401
     402However, while the guarded statements are being executed, including any
     403invoked functions, all the handlers in the statement are now on the search
     404path. If a resumption exception is reported and not handled further up the
     405stack they will be matched against the exception.
     406
     407Exception matching checks the handler in each catch clause in the order
     408they appear, top to bottom. If the representation of the thrown exception type
     409is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
     410(if provided) is bound to a pointer to the exception and the statements in
     411@HANDLER_BLOCK@$_i$ are executed.
     412If control reaches the end of the handler, execution continues after the
     413the raise statement that raised the handled exception.
     414
     415Like termination, if no resumption handler is found, the default handler
     416visible at the throw statement is called. It will use the best match at the
     417call sight according to \CFA's overloading rules. The default handler is
     418passed the exception given to the throw. When the default handler finishes
     419execution continues after the raise statement.
     420
     421There is a global @defaultResumptionHandler@ is polymorphic over all
     422termination exceptions and preforms a termination throw on the exception.
     423The @defaultTerminationHandler@ for that raise is matched at the original
     424raise statement (the resumption @throwResume@) and it can be customized by
    399425introducing a new or better match as well.
    400426
    401 \subsection{Resumption Marking}
     427\subsubsection{Resumption Marking}
    402428A key difference between resumption and termination is that resumption does
    403 not unwind the stack. A side effect is that when a handler is matched
    404 and run its try block (the guarded statements) and every try statement
     429not unwind the stack. A side effect that is that when a handler is matched
     430and run it's try block (the guarded statements) and every try statement
    405431searched before it are still on the stack. This can lead to the recursive
    406432resumption problem.
     
    416442}
    417443\end{cfa}
    418 When this code is executed the guarded @throwResume@ starts a
    419 search and matches the handler in the @catchResume@ clause. The handler is
    420 called and placed on the stack on top of the try-block. The second throw in the handler
    421 searches the same try block and calls another instance of the
     444When this code is executed the guarded @throwResume@ will throw, start a
     445search and match the handler in the @catchResume@ clause. This will be
     446call and placed on the stack on top of the try-block. The second throw then
     447throws and will search the same try block and put call another instance of the
    422448same handler leading to an infinite loop.
    423449
    424 While this situation is trivial and easy to avoid, much more complex cycles
     450This situation is trivial and easy to avoid, but much more complex cycles
    425451can form with multiple handlers and different exception types.
    426452
    427 To prevent this case, examined try statements on the stack are marked, so that
    428 subsequent resumption searches skip over them and continue with the next unmarked section
    429 of the stack.
    430 Unmarking occurs when that exception is handled
    431 or the search completes without finding a handler.
    432 
    433 % This might need a diagram. But it is an important part of the justification
    434 % of the design of the traversal order.
     453To prevent all of these cases we mark try statements on the stack.
     454A try statement is marked when a match check is preformed with it and an
     455exception. The statement will be unmarked when the handling of that exception
     456is completed or the search completes without finding a handler.
     457While a try statement is marked its handlers are never matched, effectify
     458skipping over it to the next try statement.
    435459
    436460\begin{center}
    437 %\begin{verbatim}
    438 %       throwResume2 ----------.
    439 %            |                 |
    440 % generated from handler       |
    441 %            |                 |
    442 %         handler              |
    443 %            |                 |
    444 %        throwResume1 -----.   :
    445 %            |             |   :
    446 %           try            |   : search skip
    447 %            |             |   :
    448 %        catchResume  <----'   :
    449 %            |                 |
    450 %\end{verbatim}
    451 \input{stackMarking}
     461\input{stack-marking}
    452462\end{center}
    453463
    454 The resulting search can be understood by thinking about what is searched for
    455 termination. When a throw happens in a handler, a termination handler
    456 skips everything from the original throw to the original catch because that
    457 part of the stack is unwound. A resumption handler skips the same
    458 section of stack because it is marked.
    459 A throw in a resumption default-handler performs the same search as the original
    460 @throwResume@ because for resumption nothing has been unwound.
    461 
    462 The symmetry between resumption masking and termination searching is why this pattern was picked. Other patterns,
    463 such as marking just the handlers that caught, also work but the
    464 symmetry seems to match programmer intuition.
     464These rules mirror what happens with termination.
     465When a termination throw happens in a handler the search will not look at
     466any handlers from the original throw to the original catch because that
     467part of the stack has been unwound.
     468A resumption raise in the same situation wants to search the entire stack,
     469but it will not try to match the exception with try statements in the section
     470that would have been unwound as they are marked.
     471
     472The symmetry between resumption termination is why this pattern was picked.
     473Other patterns, such as marking just the handlers that caught, also work but
     474lack the symmetry means there are less rules to remember.
    465475
    466476\section{Conditional Catch}
    467 Both termination and resumption handler-clauses can be given an additional
    468 condition to further control which exceptions is handled:
    469 \begin{cfa}
    470 catch (EXCEPTION_TYPE [* NAME] @; CONDITION@)
     477Both termination and resumption handler clauses can be given an additional
     478condition to further control which exceptions they handle:
     479\begin{cfa}
     480catch (EXCEPTION_TYPE * [NAME] ; CONDITION)
    471481\end{cfa}
    472482First, the same semantics is used to match the exception type. Second, if the
    473483exception matches, @CONDITION@ is executed. The condition expression may
    474 reference all names in the scope of the try block and @NAME@
     484reference all names in scope at the beginning of the try block and @NAME@
    475485introduced in the handler clause. If the condition is true, then the handler
    476486matches. Otherwise, the exception search continues as if the exception type
    477487did not match.
    478488
    479 Conditional catch allows fine-gain matching based on object values as well as exception types.
    480 For example, assume the exception hierarchy @OpenFailure@ $\rightarrow$ @CreateFailure@ and these exceptions are raised by function @open@.
    481 \begin{cfa}
    482 try {
    483         f1 = open( ... ); // open raises CreateFailure/OpenFailure
    484         f2 = open( ... ); //    with the associate file
     489The condition matching allows finer matching by allowing the match to check
     490more kinds of information than just the exception type.
     491\begin{cfa}
     492try {
     493        handle1 = open( f1, ... );
     494        handle2 = open( f2, ... );
     495        handle3 = open( f3, ... );
    485496        ...
    486 } catch( CreateFailure * f ; @fd( f ) == f1@ ) {
    487         // only handle IO failure for f1
    488 } catch( OpenFailure * f ; @fd( f ) == f2@ ) {
    489         // only handle IO failure for f2
    490 }
    491 \end{cfa}
    492 Here, matching is very precise on the I/O exception and particular file with an open problem.
    493 This capability cannot be easily mimiced within the handler.
    494 \begin{cfa}
    495 try {
    496         f1 = open( ... );
    497         f2 = open( ... );
    498         ...
    499 } catch( CreateFailure * f ) {
    500         if ( @fd( f ) == f1@ ) ... else // reraise
    501 } catch( OpenFailure * f ) {
    502         if ( @fd( f ) == f2@ ) ... else // reraise
    503 }
    504 \end{cfa}
    505 When an exception @CreateFailure@ is raised, the first handler catches the
    506 derived exception and reraises it if the object is inappropriate. The reraise
    507 immediately terminates the current guarded block, which precludes the handler
    508 for the base exception @OpenFailure@ from consideration for object
    509 @f2@. Therefore, the ``catch first, then reraise'' approach is an incomplete
    510 substitute for conditional catch.
    511 
    512 \section{Reraise}
    513 \label{s:Rethrowing}
    514 \colour{red}{From Andrew: I recommend we talk about why the language doesn't
    515 have rethrows/reraises instead.}
    516 
     497} catch( IOFailure * f ; fd( f ) == f1 ) {
     498        // Only handle IO failure for f1.
     499} catch( IOFailure * f ; fd( f ) == f3 ) {
     500        // Only handle IO failure for f3.
     501}
     502// Can't handle a failure relating to f2 here.
     503\end{cfa}
     504In this example the file that experianced the IO error is used to decide
     505which handler should be run, if any at all.
     506
     507\begin{comment}
     508% I know I actually haven't got rid of them yet, but I'm going to try
     509% to write it as if I had and see if that makes sense:
     510\section{Reraising}
     511\label{s:Reraising}
    517512Within the handler block or functions called from the handler block, it is
    518513possible to reraise the most recently caught exception with @throw@ or
     
    533528is part of an unwound stack frame. To prevent this problem, a new default
    534529handler is generated that does a program-level abort.
    535 \PAB{I don't see how this is different from the normal throw/throwResume.}
     530\end{comment}
     531
     532\subsection{Comparison with Reraising}
     533A more popular way to allow handlers to match in more detail is to reraise
     534the exception after it has been caught if it could not be handled here.
     535On the surface these two features seem interchangable.
     536
     537If we used @throw;@ to start a termination reraise then these two statements
     538would have the same behaviour:
     539\begin{cfa}
     540try {
     541    do_work_may_throw();
     542} catch(exception_t * exc ; can_handle(exc)) {
     543    handle(exc);
     544}
     545\end{cfa}
     546
     547\begin{cfa}
     548try {
     549    do_work_may_throw();
     550} catch(exception_t * exc) {
     551    if (can_handle(exc)) {
     552        handle(exc);
     553    } else {
     554        throw;
     555    }
     556}
     557\end{cfa}
     558If there are further handlers after this handler only the first version will
     559check them. If multiple handlers on a single try block could handle the same
     560exception the translations get more complex but they are equivilantly
     561powerful.
     562
     563Until stack unwinding comes into the picture. In termination handling, a
     564conditional catch happens before the stack is unwound, but a reraise happens
     565afterwards. Normally this might only cause you to loose some debug
     566information you could get from a stack trace (and that can be side stepped
     567entirely by collecting information during the unwind). But for \CFA there is
     568another issue, if the exception isn't handled the default handler should be
     569run at the site of the original raise.
     570
     571There are two problems with this: the site of the original raise doesn't
     572exist anymore and the default handler might not exist anymore. The site will
     573always be removed as part of the unwinding, often with the entirety of the
     574function it was in. The default handler could be a stack allocated nested
     575function removed during the unwind.
     576
     577This means actually trying to pretend the catch didn't happening, continuing
     578the original raise instead of starting a new one, is infeasible.
     579That is the expected behaviour for most languages and we can't replicate
     580that behaviour.
    536581
    537582\section{Finally Clauses}
    538 Finally clauses are used to perform unconditional clean-up when leaving a
    539 scope and appear at the end of a try statement after any catch clauses:
     583\label{s:FinallyClauses}
     584Finally clauses are used to preform unconditional clean-up when leaving a
     585scope and are placed at the end of a try statement after any handler clauses:
    540586\begin{cfa}
    541587try {
     
    548594The @FINALLY_BLOCK@ is executed when the try statement is removed from the
    549595stack, including when the @GUARDED_BLOCK@ finishes, any termination handler
    550 finishes, or during an unwind.
     596finishes or during an unwind.
    551597The only time the block is not executed is if the program is exited before
    552598the stack is unwound.
    553599
    554600Execution of the finally block should always finish, meaning control runs off
    555 the end of the block. This requirement ensures execution always continues as if the
    556 finally clause is not present, \ie @finally@ is for cleanup not changing control
    557 flow. Because of this requirement, local control flow out of the finally block
     601the end of the block. This requirement ensures control always continues as if
     602the finally clause is not present, \ie finally is for cleanup not changing
     603control flow.
     604Because of this requirement, local control flow out of the finally block
    558605is forbidden. The compiler precludes any @break@, @continue@, @fallthru@ or
    559606@return@ that causes control to leave the finally block. Other ways to leave
    560607the finally block, such as a long jump or termination are much harder to check,
    561 and at best require additional run-time overhead, and so are
     608and at best requiring additional run-time overhead, and so are only
    562609discouraged.
    563610
    564 Not all languages with exceptions have finally clauses. Notably \Cpp does
    565 without it as destructors serve a similar role. Although destructors and
    566 finally clauses can be used in many of the same areas, they have their own
     611Not all languages with unwinding have finally clauses. Notably \Cpp does
     612without it as descructors serve a similar role. Although destructors and
     613finally clauses can be used in many of the same areas they have their own
    567614use cases like top-level functions and lambda functions with closures.
    568615Destructors take a bit more work to set up but are much easier to reuse while
    569 finally clauses are good for one-off situations and can easily include local information.
     616finally clauses are good for one-off uses and
     617can easily include local information.
    570618
    571619\section{Cancellation}
    572620\label{s:Cancellation}
    573 Cancellation is a stack-level abort, which can be thought of as an
    574 uncatchable termination. It unwinds the entire stack, and when
    575 possible, forwards the cancellation exception to a different stack.
     621Cancellation is a stack-level abort, which can be thought of as as an
     622uncatchable termination. It unwinds the entire current stack, and if
     623possible forwards the cancellation exception to a different stack.
    576624
    577625Cancellation is not an exception operation like termination or resumption.
    578626There is no special statement for starting a cancellation; instead the standard
    579627library function @cancel_stack@ is called passing an exception. Unlike a
    580 throw, this exception is not used in matching only to pass information about
     628raise, this exception is not used in matching only to pass information about
    581629the cause of the cancellation.
    582 (This semantics also means matching cannot fail so there is no default handler.)
    583 
    584 After @cancel_stack@ is called, the exception is copied into the EHM's
    585 memory and the current stack is
     630(This also means matching cannot fail so there is no default handler.)
     631
     632After @cancel_stack@ is called the exception is copied into the EHM's memory
     633and the current stack is
    586634unwound. After that it depends one which stack is being cancelled.
    587635\begin{description}
    588636\item[Main Stack:]
    589637The main stack is the one used by the program main at the start of execution,
    590 and is the only stack in a sequential program. Even in a concurrent program,
    591 the main stack is often used as the environment to start the concurrent threads.
    592 Hence, when the main stack is cancelled there is nowhere else in the program
    593 to go. Hence, after the main stack is unwound, there is a program-level abort.
     638and is the only stack in a sequential program.
     639After the main stack is unwound there is a program-level abort.
     640
     641There are two reasons for this. The first is that it obviously had to do this
     642in a sequential program as there is nothing else to notify and the simplicity
     643of keeping the same behaviour in sequential and concurrent programs is good.
     644Also, even in concurrent programs there is no stack that an innate connection
     645to, so it would have be explicitly managed.
    594646
    595647\item[Thread Stack:]
    596 A thread stack is created for a \CFA @thread@ object or object that satisfies the
    597 @is_thread@ trait. A thread only has two points of communication that must
    598 happen: start and join. A thread must be running to perform a
    599 cancellation (a thread cannot cancel another thread). Therefore, a cancellation must
    600 occur after start and before join, so join is used
    601 for cancellation communication.
    602 After the stack is unwound, the thread halts and waits for
    603 another thread to join with it. The joining thread checks for a cancellation,
    604 and if present, resumes exception @ThreadCancelled@.
    605 
    606 \begin{sloppypar}
    607 There is a subtle difference between the explicit join (@join@ function) and
    608 implicit join (from a @thread@'s destructor call). The explicit join takes the default
    609 handler (@defaultResumptionHandler@) from its calling context, which is used if
    610 the exception is not caught. The implicit join does a program abort instead.
    611 \end{sloppypar}
    612 
    613 \PAB{uC++ does not have these issues, but catch(...) is not working.}
    614 \begin{lstlisting}[language=uC++]
    615 #include <iostream>
    616 using namespace std;
    617 
    618 struct Cl {
    619         ~Cl() { cout << "C" << endl; }
    620 };
    621 _Coroutine C {
    622         void main() {
    623                 Cl c;
    624                 try {
    625                         cancel();
    626                 } catch( ... ) {
    627                         cout << "..." << endl;
    628                 } _Finally {
    629                         cout << "F" << endl;
    630                 }
    631                 }
    632   public:
    633         void mem() { resume(); }
    634 };
    635 _Task T {
    636         void main() {
    637                 Cl c;
    638                 try {
    639                         cancel();
    640                 } catch( ... ) {
    641                         cout << "..." << endl;
    642                 } _Finally {
    643                         cout << "F" << endl;
    644                 }
    645         }
    646 };
    647 int main() {
    648         C c;
    649         cout << "here1" << endl;
    650         c.mem();
    651         cout << "here2" << endl;
    652         {
    653                 T t;
    654         }
    655         cout << "here3" << endl;
    656 }
    657 \end{lstlisting}
    658 
    659 \PAB{This discussion should be its own section.}
    660 This semantics is for safety. If an unwind is triggered while another unwind
    661 is underway only one of them can proceed as they both want to ``consume" the
    662 stack. Letting both try to proceed leads to very undefined behaviour.
    663 Both termination and cancellation involve unwinding and, since the default
    664 @defaultResumptionHandler@ preforms a termination that could more easily
    665 happen in an implicate join inside a destructor. So there is an error message
    666 and an abort instead.
    667 
    668 \todo{Perhaps have a more general disucssion of unwind collisions before
    669 this point.}
    670 
    671 The recommended way to avoid the abort is to handle the initial resumption
    672 from the implicate join. If required you may put an explicate join inside a
    673 finally clause to disable the check and use the local
    674 @defaultResumptionHandler@ instead.
    675 
    676 \item[Coroutine Stack:] A coroutine stack is created for a @coroutine@ object
    677 or object that satisfies the @is_coroutine@ trait. A coroutine only knows of
    678 two other coroutines, its starter and its last resumer. Of the two the last
    679 resumer has the tightest coupling to the coroutine it activated and the most
    680 up-to-date information.
    681 
    682 Hence, cancellation of the active coroutine is forwarded to the last resumer
    683 after the stack is unwound. When the resumer restarts, it resumes exception
    684 @CoroutineCancelled@, which is polymorphic over the coroutine type and has a
    685 pointer to the cancelled coroutine.
    686 
    687 The resume function also has an assertion that the @defaultResumptionHandler@
    688 for the exception. So it will use the default handler like a regular throw.
     648A thread stack is created for a \CFA @thread@ object or object that satisfies
     649the @is_thread@ trait.
     650After a thread stack is unwound there exception is stored until another
     651thread attempts to join with it. Then the exception @ThreadCancelled@,
     652which stores a reference to the thread and to the exception passed to the
     653cancellation, is reported from the join.
     654There is one difference between an explicit join (with the @join@ function)
     655and an implicit join (from a destructor call). The explicit join takes the
     656default handler (@defaultResumptionHandler@) from its calling context while
     657the implicit join provides its own which does a program abort if the
     658@ThreadCancelled@ exception cannot be handled.
     659
     660Communication is done at join because a thread only has to have to points of
     661communication with other threads: start and join.
     662Since a thread must be running to perform a cancellation (and cannot be
     663cancelled from another stack), the cancellation must be after start and
     664before the join. So join is the one that we will use.
     665
     666% TODO: Find somewhere to discuss unwind collisions.
     667The difference between the explicit and implicit join is for safety and
     668debugging. It helps prevent unwinding collisions by avoiding throwing from
     669a destructor and prevents cascading the error across multiple threads if
     670the user is not equipped to deal with it.
     671Also you can always add an explicit join if that is the desired behaviour.
     672
     673\item[Coroutine Stack:]
     674A coroutine stack is created for a @coroutine@ object or object that
     675satisfies the @is_coroutine@ trait.
     676After a coroutine stack is unwound control returns to the resume function
     677that most recently resumed it. The resume statement reports a
     678@CoroutineCancelled@ exception, which contains a references to the cancelled
     679coroutine and the exception used to cancel it.
     680The resume function also takes the @defaultResumptionHandler@ from the
     681caller's context and passes it to the internal report.
     682
     683A coroutine knows of two other coroutines, its starter and its last resumer.
     684The starter has a much more distant connection while the last resumer just
     685(in terms of coroutine state) called resume on this coroutine, so the message
     686is passed to the latter.
    689687\end{description}
    690 
    691 \PAB{You should have more test programs that compare \CFA EHM to uC++ EHM.}
  • doc/theses/andrew_beach_MMath/uw-ethesis.tex

    rd2fadeb r59f3f61  
    7474% ======================================================================
    7575%   D O C U M E N T   P R E A M B L E
    76 % Specify the document class, default style attributes, page dimensions, etc.
    77 % For hyperlinked PDF, suitable for viewing on a computer, use this:
    78 \documentclass[letterpaper,12pt,titlepage,oneside,final]{book}
    79 
    80 % For PDF, suitable for double-sided printing, change the PrintVersion
    81 % variable below to "true" and use this \documentclass line instead of the
    82 % one above:
    83 %\documentclass[letterpaper,12pt,titlepage,openright,twoside,final]{book}
    84 
    85 \usepackage{etoolbox}
     76\RequirePackage{etoolbox}
     77
     78% Control if this for print (set true) or will stay digital (default).
     79% Print is two sided, digital uses more colours.
     80\newtoggle{printversion}
     81%\toggletrue{printversion}
     82
     83\iftoggle{printversion}{%
     84  \documentclass[letterpaper,12pt,titlepage,openright,twoside,final]{book}
     85}{%
     86  \documentclass[letterpaper,12pt,titlepage,oneside,final]{book}
     87}
    8688
    8789% Some LaTeX commands I define for my own nomenclature.
     
    9496% Anything defined here may be redefined by packages added below...
    9597
    96 % This package allows if-then-else control structures.
    97 \usepackage{ifthen}
    98 \newboolean{PrintVersion}
    99 \setboolean{PrintVersion}{false}
    100 % CHANGE THIS VALUE TO "true" as necessary, to improve printed results for
    101 % hard copies by overriding some options of the hyperref package, called below.
    102 
    103 %\usepackage{nomencl} % For a nomenclature (optional; available from ctan.org)
     98% For a nomenclature (optional; available from ctan.org)
     99%\usepackage{nomencl}
    104100% Lots of math symbols and environments
    105101\usepackage{amsmath,amssymb,amstext}
    106 % For including graphics N.B. pdftex graphics driver
    107 %\usepackage[pdftex]{graphicx}
     102% For including graphics (must match graphics driver)
    108103\usepackage{epic,eepic}
    109104\usepackage{graphicx}
     
    113108\usepackage{todonotes}
    114109
    115 
    116110% Hyperlinks make it very easy to navigate an electronic document.
    117111% In addition, this is where you should specify the thesis title and author as
     
    119113% Use the "hyperref" package
    120114% N.B. HYPERREF MUST BE THE LAST PACKAGE LOADED; ADD ADDITIONAL PKGS ABOVE
    121 %\usepackage[pdftex,pagebackref=true]{hyperref} % with basic options
    122 \usepackage[pagebackref=true]{hyperref} % with basic options
    123 %\usepackage[pdftex,pagebackref=true]{hyperref}
     115\usepackage[pagebackref=true]{hyperref}
    124116% N.B. pagebackref=true provides links back from the References to the body
    125117% text. This can cause trouble for printing.
     
    131123    pdffitwindow=false,     % window fit to page when opened
    132124    pdfstartview={FitH},    % fits the width of the page to the window
    133 %    pdftitle={uWaterloo\ LaTeX\ Thesis\ Template}, % title: CHANGE THIS TEXT!
    134 %    pdfauthor={Author},    % author: CHANGE THIS TEXT! and uncomment this line
    135 %    pdfsubject={Subject},  % subject: CHANGE THIS TEXT! and uncomment this line
    136 %    pdfkeywords={keyword1} {key2} {key3}, % optional list of keywords
    137125    pdfnewwindow=true,      % links in new window
    138126    colorlinks=true,        % false: boxed links; true: colored links
    139     linkcolor=blue,         % color of internal links
    140     citecolor=green,        % color of links to bibliography
    141     filecolor=magenta,      % color of file links
    142     urlcolor=cyan           % color of external links
    143127}
    144 % for improved print quality, change some hyperref options
    145 \ifthenelse{\boolean{PrintVersion}}{
    146 \hypersetup{    % override some previously defined hyperref options
    147 %    colorlinks,%
    148     citecolor=black,%
    149     filecolor=black,%
    150     linkcolor=black,%
    151     urlcolor=black}
    152 }{} % end of ifthenelse (no else)
     128\iftoggle{printversion}{
     129  \hypersetup{
     130    citecolor=black,        % colour of links to bibliography
     131    filecolor=black,        % colour of file links
     132    linkcolor=black,        % colour of internal links
     133    urlcolor=black,         % colour of external links
     134  }
     135}{ % Digital Version
     136  \hypersetup{
     137    citecolor=green,
     138    filecolor=magenta,
     139    linkcolor=blue,
     140    urlcolor=cyan,
     141  }
     142}
     143
     144\hypersetup{
     145  pdftitle={Exception Handling in Cforall},
     146  pdfauthor={Andrew James Beach},
     147  pdfsubject={Computer Science},
     148  pdfkeywords={programming languages} {exceptions}
     149      {language design} {language implementation},
     150}
    153151
    154152% Exception to the rule of hyperref being the last add-on package
     
    220218\pdfstringdefDisableCommands{\def\Cpp{C++}}
    221219
     220% Wrappers for inline code snippits.
     221\newrobustcmd*\codeCFA[1]{\lstinline[language=CFA]{#1}}
     222\newrobustcmd*\codeC[1]{\lstinline[language=C]{#1}}
     223\newrobustcmd*\codeCpp[1]{\lstinline[language=C++]{#1}}
     224\newrobustcmd*\codePy[1]{\lstinline[language=Python]{#1}}
     225
    222226% Colour text, formatted in LaTeX style instead of TeX style.
    223227\newcommand*\colour[2]{{\color{#1}#2}}
Note: See TracChangeset for help on using the changeset viewer.