Changeset 8d66610 for doc/theses/andrew_beach_MMath/features.tex
- Timestamp:
- May 21, 2021, 4:48:10 PM (5 years ago)
- Branches:
- ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum, stuck-waitfor-destruct
- Children:
- f1bce515
- Parents:
- 5407cdc (diff), 7404cdc (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. - File:
-
- 1 edited
-
doc/theses/andrew_beach_MMath/features.tex (modified) (16 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/andrew_beach_MMath/features.tex
r5407cdc r8d66610 20 20 \subparagraph{Raise} 21 21 The raise is the starting point for exception handling. It marks the beginning 22 of exception handling by \newterm{raising}an excepion, which passes it to22 of exception handling by raising an excepion, which passes it to 23 23 the EHM. 24 24 25 25 Some well known examples include the @throw@ statements of \Cpp and Java and 26 the \code Py{raise} statement from Python. In real systems a raise may preform27 some other work (such as memory management) but for the purposes of this 28 overview that can be ignored.26 the \code{Python}{raise} statement from Python. In real systems a raise may 27 preform some other work (such as memory management) but for the 28 purposes of this overview that can be ignored. 29 29 30 30 \subparagraph{Handle} … … 93 93 A handler labelled with any given exception can handle exceptions of that 94 94 type or any child type of that exception. The root of the exception hierarchy 95 (here \code C{exception}) acts as a catch-all, leaf types catch single types95 (here \code{C}{exception}) acts as a catch-all, leaf types catch single types 96 96 and the exceptions in the middle can be used to catch different groups of 97 97 related exceptions. … … 101 101 between different sub-hierarchies. 102 102 This design is used in \CFA even though it is not a object-orientated 103 language using different toolsto create the hierarchy.103 language; so different tools are used to create the hierarchy. 104 104 105 105 % Could I cite the rational for the Python IO exception rework? … … 123 123 \section{Virtuals} 124 124 Virtual types and casts are not part of \CFA's EHM nor are they required for 125 any EHM. But \CFA uses a hierarchial system of exceptions and this feature 126 is 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. 125 any EHM. 126 However the \CFA uses a hierarchy built with the virtual system as the basis 127 for exceptions and exception matching. 128 129 The virtual system would have ideally been part of \CFA before the work 130 on exception handling began, but unfortunately it was not. 131 Because of this only the features and framework needed for the EHM were 132 designed and implemented. Other features were considered to ensure that 133 the structure could accomidate other desirable features but they were not 134 implemented. 135 The rest of this section will only discuss the finalized portion of the 136 virtual system. 130 137 131 138 The virtual system supports multiple ``trees" of types. Each tree is … … 143 150 It is important to note that these are virtual members, not virtual methods 144 151 of object-orientated programming, and can be of any type. 145 However, since \CFA has function pointers and they are allowed, virtual 146 members can be used to mimic virtual methods. 152 \CFA still supports virtual methods as a special case of virtual members. 153 Function pointers that take a pointer to the virtual type will be modified 154 with each level of inheritance so that refers to the new type. 155 This means an object can always be passed to a function in its virtual table 156 as if it were a method. 147 157 148 158 Each virtual type has a unique id. … … 175 185 While much of the virtual infrastructure is created, it is currently only used 176 186 internally for exception handling. The only user-level feature is the virtual 177 cast, which is the same as the \Cpp \ lstinline[language=C++]|dynamic_cast|.187 cast, which is the same as the \Cpp \code{C++}{dynamic_cast}. 178 188 \label{p:VirtualCast} 179 189 \begin{cfa} … … 197 207 \begin{cfa} 198 208 trait is_exception(exceptT &, virtualT &) { 199 virtualT const & get_exception_vtable(exceptT *);209 // Numerous imaginary assertions. 200 210 }; 201 211 \end{cfa} 202 212 The trait is defined over two types, the exception type and the virtual table 203 type. This should be one-to-one: each exception type has only one virtual 204 table type and vice versa. The only assertion in the trait is 205 @get_exception_vtable@, which takes a pointer of the exception type and 206 returns 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. 210 The function @get_exception_vtable@ is actually a constant function. 211 Regardless of the value passed in (including the null pointer) it should 212 return a reference to the virtual table instance for that type. 213 The reason it is a function instead of a constant is that it make type 214 annotations easier to write as you can use the exception type instead of the 215 virtual table type; which usually has a mangled name. 216 % Also \CFA's trait system handles functions better than constants and doing 217 % it this way reduce the amount of boiler plate we need. 213 type. Each exception type should have but a single virtual table type. 214 Now there are no actual assertions in this trait because the trait system 215 actually can't express them (adding such assertions would be part of 216 completing the virtual system). The imaginary assertions would probably come 217 from a trait defined by the virtual system, and state that the exception type 218 is a virtual type, is a decendent of @exception_t@ (the base exception type) 219 and note its virtual table type. 218 220 219 221 % I did have a note about how it is the programmer's responsibility to make … … 235 237 Both traits ensure a pair of types are an exception type and its virtual table 236 238 and defines one of the two default handlers. The default handlers are used 237 as fallbacks and are discussed in detail in \ VRef{s:ExceptionHandling}.239 as fallbacks and are discussed in detail in \vref{s:ExceptionHandling}. 238 240 239 241 However, all three of these traits can be tricky to use directly. … … 351 353 for particular exception type. 352 354 The global default termination handler performs a cancellation 353 \see{\VRef{s:Cancellation}}on the current stack with the copied exception.355 (see \vref{s:Cancellation}) on the current stack with the copied exception. 354 356 355 357 \subsection{Resumption} … … 426 428 427 429 \subsubsection{Resumption Marking} 430 \label{s:ResumptionMarking} 428 431 A key difference between resumption and termination is that resumption does 429 432 not unwind the stack. A side effect that is that when a handler is matched … … 472 475 The symmetry between resumption termination is why this pattern was picked. 473 476 Other patterns, such as marking just the handlers that caught, also work but 474 lack the symmetry means there are lessrules to remember.477 lack the symmetry means there are more rules to remember. 475 478 476 479 \section{Conditional Catch} … … 557 560 \end{cfa} 558 561 If there are further handlers after this handler only the first version will 559 check them. If multiple handlers on a single try block could handle the same560 exception the translations get more complex but they are equivilantly562 check them. If multiple handlers on a single try block that could handle the 563 same exception the translations get more complex but they are equivilantly 561 564 powerful. 562 565 … … 633 636 and the current stack is 634 637 unwound. After that it depends one which stack is being cancelled. 635 \begin{description} 636 \ item[Main Stack:]638 639 \paragraph{Main Stack} 637 640 The main stack is the one used by the program main at the start of execution, 638 641 and is the only stack in a sequential program. … … 645 648 to, so it would have be explicitly managed. 646 649 647 \ item[Thread Stack:]650 \paragraph{Thread Stack} 648 651 A thread stack is created for a \CFA @thread@ object or object that satisfies 649 652 the @is_thread@ trait. … … 671 674 Also you can always add an explicit join if that is the desired behaviour. 672 675 673 \ item[Coroutine Stack:]676 \paragraph{Coroutine Stack} 674 677 A coroutine stack is created for a @coroutine@ object or object that 675 678 satisfies the @is_coroutine@ trait. … … 685 688 (in terms of coroutine state) called resume on this coroutine, so the message 686 689 is passed to the latter. 687 \end{description}
Note:
See TracChangeset
for help on using the changeset viewer.
