Index: doc/theses/andrew_beach_MMath/features.tex =================================================================== --- doc/theses/andrew_beach_MMath/features.tex (revision f93d7fc7d039f77b2be3d58e385d38f6a309824c) +++ doc/theses/andrew_beach_MMath/features.tex (revision b041f11daf89e03f45478e73f7bf4f1f5d9806e2) @@ -152,6 +152,6 @@ % A type's descendants are its children and its children's descendants. -For the purposes of illustration, a proposed -- but unimplemented syntax -- -will be used. Each virtual type is represented by a trait with an annotation +For the purposes of illistration, a proposed -- but unimplemented syntax -- +will be used. Each virtual type is repersented by a trait with an annotation that makes it a virtual type. This annotation is empty for a root type, which creates a new tree: @@ -192,5 +192,5 @@ As @child_type@ is a child of @root_type@ it has the virtual members of @root_type@ (@to_string@ and @size@) as well as the one it declared -(@irrelevant_function@). +(@irrelivant_function@). It is important to note that these are virtual members, and may contain @@ -282,6 +282,6 @@ Fields are filled in the same way as a structure as well. However an extra -field is added that contains the pointer to the virtual table. -It must be explicitly initialized by the user when the exception is +field is added, this field contains the pointer to the virtual table. +It must be explicitly initialised by the user when the exception is constructed. @@ -310,10 +310,10 @@ %\subsection{Exception Details} -This is the only interface needed when raising and handling exceptions. -However it is actually a short hand for a more complex +If one is only raising and handling exceptions, that is the only interface +that is needed. However it is actually a short hand for a more complex trait based interface. -The language views exceptions through a series of traits. -If a type satisfies them, then it can be used as an exception. The following +The language views exceptions through a series of traits, +if a type satisfies them, then it can be used as an exception. The following is the base trait all exceptions need to match. \begin{cfa} @@ -322,5 +322,5 @@ }; \end{cfa} -The trait is defined over two types: the exception type and the virtual table +The trait is defined over two types, the exception type and the virtual table type. Each exception type should have a single virtual table type. There are no actual assertions in this trait because the trait system @@ -347,5 +347,5 @@ }; \end{cfa} -Both traits ensure a pair of types is an exception type, its virtual table +Both traits ensure a pair of types are an exception type, its virtual table type and defines one of the two default handlers. The default handlers are used @@ -393,5 +393,5 @@ The differences between the two operations include how propagation is -performed, where execution after an exception is handler +performed, where excecution after an exception is handler and which default handler is run. Index: doc/theses/andrew_beach_MMath/implement.tex =================================================================== --- doc/theses/andrew_beach_MMath/implement.tex (revision f93d7fc7d039f77b2be3d58e385d38f6a309824c) +++ doc/theses/andrew_beach_MMath/implement.tex (revision b041f11daf89e03f45478e73f7bf4f1f5d9806e2) @@ -51,5 +51,5 @@ The problem is that a type id may appear in multiple TUs that compose a program (see \autoref{ss:VirtualTable}); so the initial solution would seem -to be make it external in each translation unit. However, the type id must +to be make it external in each translation unit. Honever, the type id must have a declaration in (exactly) one of the TUs to create the storage. No other declaration related to the virtual type has this property, so doing @@ -183,5 +183,5 @@ The second section are all the virtual members of the parent, in the same order as they appear in the parent's virtual table. Note that the type may -change slightly as references to the ``this" change. This is limited to +change slightly as references to the ``this" will change. This is limited to inside pointers/references and via function pointers so that the size (and hence the offsets) are the same. @@ -216,10 +216,10 @@ type's alignment, is set using an @alignof@ expression. -Most of these tools are already inside the compiler. Using a simple -code transformation early on in compilation, allows most of the work to be +Most of these tools are already inside the compiler. Using the is a simple +code transformation early on in compilation allows most of that work to be handed off to the existing tools. \autoref{f:VirtualTableTransformation} shows an example transformation, this example shows an exception virtual table. -It also shows the transformation on the full declaration. -For a forward declaration, the @extern@ keyword is preserved and the +It also shows the transformation on the full declaration, +for a forward declaration the @extern@ keyword is preserved and the initializer is not added. @@ -333,5 +333,5 @@ the exceptions themselves and the virtual system interactions. -Creating an exception type is just a matter of prepending the field +Creating an exception type is just a matter of preppending the field with the virtual table pointer to the list of the fields (see \autoref{f:ExceptionTypeTransformation}). @@ -364,17 +364,17 @@ the types of the virtual table and the type id, are generated when the virtual type (the exception) is first found. -The type id (the instance) is generated with the exception, if it is +The type id (the instance) is generated with the exception if it is a monomorphic type. -However, if the exception is polymorphic, then a different type id has to -be generated for every instance. In this case, generation is delayed +However if the exception is polymorphic then a different type id has to +be generated for every instance. In this case generation is delayed until a virtual table is created. % There are actually some problems with this, which is why it is not used % for monomorphic types. -When a virtual table is created and initialized, two functions are created +When a virtual table is created and initialized two functions are created to fill in the list of virtual members. -The first is a copy function that adapts the exception's copy constructor +The first is a copy function which adapts the exception's copy constructor to work with pointers, avoiding some issues with the current copy constructor interface. -Second is the msg function that returns a C-string with the type's name, +Second is the msg function, which returns a C-string with the type's name, including any polymorphic parameters. @@ -405,5 +405,5 @@ Unwinding across multiple stack frames is more complex because that information is no longer contained within the current function. -With separate compilation, +With seperate compilation, a function does not know its callers nor their frame layout. Even using the return address, that information is encoded in terms of @@ -479,5 +479,5 @@ To get full unwinding support, all of these features must be handled directly -in assembly and assembler directives; particularly the cfi directives +in assembly and assembler directives; partiularly the cfi directives \snake{.cfi_lsda} and \snake{.cfi_personality}. @@ -894,5 +894,5 @@ \autoref{f:ResumptionTransformation} shows the pattern used to transform -a \CFA try statement with catch clauses into the appropriate C functions. +a \CFA try statement with catch clauses into the approprate C functions. \todo{Explain the Resumption Transformation figure.}