# Changeset a6c45c6

Ignore:
Timestamp:
Apr 29, 2021, 10:58:35 AM (19 months ago)
Branches:
arm-eh, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum
Children:
2d8a770
Parents:
c1136c56
Message:

Andrew MMath: Went over the features chapter again.

File:
1 edited

Unmodified
Removed
• ## doc/theses/andrew_beach_MMath/features.tex

 rc1136c56 between different sub-hierarchies. This design is used in \CFA even though it is not a object-orientated language using different tools to create the hierarchy. language; so different tools are used to create the hierarchy. % Could I cite the rational for the Python IO exception rework? \section{Virtuals} Virtual types and casts are not part of \CFA's EHM nor are they required for any EHM. But \CFA uses a hierarchial system of exceptions and this feature is leveraged to create that. % Maybe talk about why the virtual system is so minimal. % Created for but not a part of the exception system. any EHM. However the \CFA uses a hierarchy built with the virtual system as the basis for exceptions and exception matching. The virtual system would have ideally been part of \CFA before the work on exception handling began, but unfortunately it was not. Because of this only the features and framework needed for the EHM were designed and implemented. Other features were considered to ensure that the structure could accomidate other desirable features but they were not implemented. The rest of this section will only discuss the finalized portion of the virtual system. The virtual system supports multiple trees" of types. Each tree is While much of the virtual infrastructure is created, it is currently only used internally for exception handling. The only user-level feature is the virtual cast, which is the same as the \Cpp \lstinline[language=C++]|dynamic_cast|. cast, which is the same as the \Cpp \codeCpp{dynamic_cast}. \label{p:VirtualCast} \begin{cfa} \begin{cfa} trait is_exception(exceptT &, virtualT &) { virtualT const & get_exception_vtable(exceptT *); // Numerous imaginary assertions. }; \end{cfa} The trait is defined over two types, the exception type and the virtual table type. This should be one-to-one: each exception type has only one virtual table type and vice versa. The only assertion in the trait is @get_exception_vtable@, which takes a pointer of the exception type and returns a reference to the virtual table type instance. % TODO: This section, and all references to get_exception_vtable, are % out-of-data. Perhaps wait until the update is finished before rewriting it. The function @get_exception_vtable@ is actually a constant function. Regardless of the value passed in (including the null pointer) it should return a reference to the virtual table instance for that type. The reason it is a function instead of a constant is that it make type annotations easier to write as you can use the exception type instead of the virtual table type; which usually has a mangled name. % Also \CFA's trait system handles functions better than constants and doing % it this way reduce the amount of boiler plate we need. type. Each exception type should have but a single virtual table type. Now there are no actual assertions in this trait because the trait system actually can't express them (adding such assertions would be part of completing the virtual system). The imaginary assertions would probably come from a trait defined by the virtual system, and state that the exception type is a virtual type, is a decendent of @exception_t@ (the base exception type) and note its virtual table type. % I did have a note about how it is the programmer's responsibility to make The symmetry between resumption termination is why this pattern was picked. Other patterns, such as marking just the handlers that caught, also work but lack the symmetry means there are less rules to remember. lack the symmetry means there are more rules to remember. \section{Conditional Catch} \end{cfa} If there are further handlers after this handler only the first version will check them. If multiple handlers on a single try block could handle the same exception the translations get more complex but they are equivilantly check them. If multiple handlers on a single try block that could handle the same exception the translations get more complex but they are equivilantly powerful. and the current stack is unwound. After that it depends one which stack is being cancelled. \begin{description} \item[Main Stack:] \paragraph{Main Stack} The main stack is the one used by the program main at the start of execution, and is the only stack in a sequential program. to, so it would have be explicitly managed. \item[Thread Stack:] \paragraph{Thread Stack} A thread stack is created for a \CFA @thread@ object or object that satisfies the @is_thread@ trait. Also you can always add an explicit join if that is the desired behaviour. \item[Coroutine Stack:] \paragraph{Coroutine Stack} A coroutine stack is created for a @coroutine@ object or object that satisfies the @is_coroutine@ trait. (in terms of coroutine state) called resume on this coroutine, so the message is passed to the latter. \end{description}
Note: See TracChangeset for help on using the changeset viewer.