Index: doc/theses/colby_parsons_MMAth/text/actors.tex
===================================================================
--- doc/theses/colby_parsons_MMAth/text/actors.tex	(revision 6d18ddbed6ac65a32f450a83b04e3c6ddc7058f5)
+++ doc/theses/colby_parsons_MMAth/text/actors.tex	(revision 70d8e2f21e271a433d073d382ee2a8356bb528cf)
@@ -283,12 +283,13 @@
 \subsection{Actor Send}\label{s:ActorSend}
 All message sends are done using the vertical-bar (bit-or) operator, @?|?@, similar to the syntax of the \CFA stream I/O.
-Hence, programmers must write a matching @?|?@ routine for each @receive@ routine, which is awkward and generates a maintenance problem That must be solved.
-The currently supported approach to creating a generic @?|?@ routine requires users to create specific routines for their actor and message types that access the base type.
-Since these routines are not complex, they can be generated using macros that the user can add following their message and actor types.
-This works, but is not much better than asking users to write the @?|?@ routine themselves.
+Hence, programmers must write a matching @?|?@ routine for each @receive@ routine, which is awkward and generates a maintenance problem that must be solved.
+\CFA's current best approach for creating a generic @?|?@ routine requires users to create routines for their actor and message types that access the base type.
+Since these routines are not complex, they can be generated using macros that are used to annotate the user-defined actor and message types.
+This approach is used in \CFA's intrusive list data structure.
+This is not much better than asking users to write the @?|?@ routine themselves in terms of maintenance, since the user needs to remember the boilerplate macro annotation.
 
 As stated, \CFA does not have named inheritance with RTTI.
 \CFA does have a preliminary form of virtual routines, but it is not mature enough for use in this work.
-Virtuals would provide a clean mechanism to write a single generic @?|?@ routine taking a base actor and message type, and then dynamically selecting the @receive@ routine from the actor argument.
+Virtuals would provide a mechanism to write a single generic @?|?@ routine taking a base actor and message type, that would dynamically select the @receive@ routine from the actor argument.
 Note, virtuals are not needed for the send; Plan-9 inheritance is sufficient because only the inherited fields are needed during the message send (only upcasting is needed).
 
@@ -324,13 +325,14 @@
 
 \subsection{Actor Termination}\label{s:ActorTerm}
-As discussed in Section~\ref{s:ActorSend}, during a message send, the derived type of the actor and message is erased, and then recovered later by calling the receive routine.
+During a message send, the receiving actor and message being sent are stored via pointers in the envelope.
+These pointers have the base actor and message types, so type information of the actor and message is lost and then recovered later when the typed receive routine is called.
 After the receive routine is done, the executor must clean up the actor and message according to their allocation status.
 If the allocation status is @Delete@ or @Destroy@, the appropriate destructor must be called by the executor.
-This poses a problem; the type of the actor or message is not available to the executor, but it needs to call the right destructor!
-This requires down-casting from the base type to derived type, which requires a virtual system.
+This poses a problem; the correct type of the actor or message is not available to the executor, but it needs to call the right destructor!
+This requires downcasting from the base type to derived type, which requires a virtual system.
 Thus, a rudimentary destructor-only virtual system was added to \CFA as part of this work.
-This virtual system is used via Plan-9 inheritance of the @virtual_dtor@ type.
+This virtual system is used via Plan-9 inheritance of the @virtual_dtor@ type, shown in Figure~\ref{f:VirtDtor}.
 The @virtual_dtor@ type maintains a pointer to the start of the object, and a pointer to the correct destructor.
-When a type inherits the @virtual_dtor@ type, the compiler adds code to its destructor to make sure that whenever any destructor along inheritance tree is called, the destructor call is intercepted, and restarts at the appropriate destructor for that object.
+When a type inherits the @virtual_dtor@ type, the compiler adds code to its destructor to make sure that any destructor calls along this segment of the inheritance tree is called are intercepted, and restart at the appropriate destructor for that object.
 
 \begin{figure}
@@ -344,5 +346,7 @@
     intermediate_type & i = d2;
     base_type & b = d3;
-    ^d1{}; ^i{}; ^b{}; // all of these will call the destructors in the correct order
+
+    // these will call the destructors in the correct order
+    ^d1{}; ^i{}; ^b{}; 
 }