Index: doc/proposals/concurrency/text/basics.tex
===================================================================
--- doc/proposals/concurrency/text/basics.tex	(revision 64b272aedd6db65f570acb3d386065b1438f00f8)
+++ doc/proposals/concurrency/text/basics.tex	(revision a2ea829dc9b8ad1d478141b95be3b1e4b558d102)
@@ -9,17 +9,17 @@
 At its core, concurrency is based on having multiple call-stacks and scheduling among threads of execution executing on these stacks. Concurrency without parallelism only requires having multiple call stacks (or contexts) for a single thread of execution.
 
-Indeed, while execution with a single thread and multiple stacks where the thread is self-scheduling deterministically across the stacks is called coroutining, execution with a single and multiple stacks but where the thread is scheduled by an oracle (non-deterministic from the thread perspective) across the stacks is called concurrency.
-
-Therefore, a minimal concurrency system can be achieved by creating coroutines, which instead of context switching among each other, always ask an oracle where to context switch next. While coroutines can execute on the caller's stack-frame, stackfull coroutines allow full generality and are sufficient as the basis for concurrency. The aforementioned oracle is a scheduler and the whole system now follows a cooperative threading-model \cit. The oracle/scheduler can either be a stackless or stackfull entity and correspondingly require one or two context switches to run a different coroutine. In any case, a subset of concurrency related challenges start to appear. For the complete set of concurrency challenges to occur, the only feature missing is preemption. Indeed, concurrency challenges appear with non-determinism. Using mutual-exclusion or synchronisation are ways of limiting the lack of determinism in a system. A scheduler introduces order of execution uncertainty, while preemption introduces uncertainty about where context-switches occur. Now it is important to understand that uncertainty is not undesireable; uncertainty can often be used by systems to significantly increase performance and is often the basis of giving a user the illusion that tasks are running in parallel. Optimal performance in concurrent applications is often obtained by having as much non-determinism as correctness allows\cit.
+Execution with a single thread and multiple stacks where the thread is self-scheduling deterministically across the stacks is called coroutining. Execution with a single and multiple stacks but where the thread is scheduled by an oracle (non-deterministic from the thread perspective) across the stacks is called concurrency.
+
+Therefore, a minimal concurrency system can be achieved by creating coroutines, which instead of context switching among each other, always ask an oracle where to context switch next. While coroutines can execute on the caller's stack-frame, stackfull coroutines allow full generality and are sufficient as the basis for concurrency. The aforementioned oracle is a scheduler and the whole system now follows a cooperative threading-model \cit. The oracle/scheduler can either be a stackless or stackfull entity and correspondingly require one or two context switches to run a different coroutine. In any case, a subset of concurrency related challenges start to appear. For the complete set of concurrency challenges to occur, the only feature missing is preemption.
+
+A scheduler introduces order of execution uncertainty, while preemption introduces uncertainty about where context-switches occur. Mutual-exclusion and synchronisation are ways of limiting non-determinism in a concurrent system. Now it is important to understand that uncertainty is desireable; uncertainty can be used by runtime systems to significantly increase performance and is often the basis of giving a user the illusion that tasks are running in parallel. Optimal performance in concurrent applications is often obtained by having as much non-determinism as correctness allows\cit.
 
 \section{\protect\CFA 's Thread Building Blocks}
-One of the important features that is missing in C is threading. On modern architectures, a lack of threading is unacceptable\cite{Sutter05, Sutter05b}, and therefore modern programming languages must have the proper tools to allow users to write performant concurrent and/or parallel programs. As an extension of C, \CFA needs to express these concepts in a way that is as natural as possible to programmers familiar with imperative languages. And being a system-level language means programmers expect to choose precisely which features they need and which cost they are willing to pay.
+One of the important features that is missing in C is threading. On modern architectures, a lack of threading is unacceptable\cite{Sutter05, Sutter05b}, and therefore modern programming languages must have the proper tools to allow users to write performant concurrent programs to take advantage of parallelism. As an extension of C, \CFA needs to express these concepts in a way that is as natural as possible to programmers familiar with imperative languages. And being a system-level language means programmers expect to choose precisely which features they need and which cost they are willing to pay.
 
 \section{Coroutines: A stepping stone}\label{coroutine}
-While the main focus of this proposal is concurrency and parallelism, it is important to address coroutines, which are actually a significant building block of a concurrency system. Coroutines need to deal with context-switchs and other context-management operations. Therefore, this proposal includes coroutines both as an intermediate step for the implementation of threads, and a first class feature of \CFA. Furthermore, many design challenges of threads are at least partially present in designing coroutines, which makes the design effort that much more relevant. The core \acrshort{api} of coroutines revolve around two features: independent call stacks and \code{suspend}/\code{resume}.
-
-A good example of a problem made easier with coroutines is genereting the fibonacci sequence. This problem comes with the challenge of decoupling how a sequence is generated and how it is used. Figure \ref{fig:fibonacci-c} shows conventional approaches to writing generators in C. All three of these approach suffer from strong coupling. The left and center approaches require that the generator have knowledge of how the sequence will be used, while the rightmost approach requires to user to hold internal state between calls on behalf of th sequence generator and makes it much harder to handle corner cases like the Fibonacci seed.
+While the main focus of this proposal is concurrency and parallelism, it is important to address coroutines, which are actually a significant building block of a concurrency system. Coroutines need to deal with context-switches and other context-management operations. Therefore, this proposal includes coroutines both as an intermediate step for the implementation of threads, and a first class feature of \CFA. Furthermore, many design challenges of threads are at least partially present in designing coroutines, which makes the design effort that much more relevant. The core \acrshort{api} of coroutines revolve around two features: independent call stacks and \code{suspend}/\code{resume}.
+
 \begin{figure}
-\label{fig:fibonacci-c}
 \begin{center}
 \begin{tabular}{c @{\hskip 0.025in}|@{\hskip 0.025in} c @{\hskip 0.025in}|@{\hskip 0.025in} c}
@@ -45,4 +45,17 @@
 	}
 }
+
+int main() {
+	void print_fib(int n) {
+		printf("%d\n", n);
+	}
+
+	fibonacci_func(
+		10, print_fib
+	);
+
+
+
+}
 \end{ccode}&\begin{ccode}[tabsize=2]
 //Using output array
@@ -62,7 +75,20 @@
 			f2 = next;
 		}
-		*array = next;
-		array++;
-	}
+		array[i] = next;
+	}
+}
+
+
+int main() {
+	int a[10];
+
+	fibonacci_func(
+		10, a
+	);
+
+	for(int i=0;i<10;i++){
+		printf("%d\n", a[i]);
+	}
+
 }
 \end{ccode}&\begin{ccode}[tabsize=2]
@@ -70,13 +96,13 @@
 typedef struct {
 	int f1, f2;
-} iterator_t;
+} Iterator_t;
 
 int fibonacci_state(
-	iterator_t * it
+	Iterator_t * it
 ) {
 	int f;
 	f = it->f1 + it->f2;
 	it->f2 = it->f1;
-	it->f1 = f;
+	it->f1 = max(f,1);
 	return f;
 }
@@ -87,15 +113,29 @@
 
 
+
+int main() {
+	Iterator_t it={0,0};
+
+	for(int i=0;i<10;i++){
+		printf("%d\n",
+			fibonacci_state(
+				&it
+			);
+		);
+	}
+
+}
 \end{ccode}
 \end{tabular}
 \end{center}
 \caption{Different implementations of a fibonacci sequence generator in C.}
+\label{lst:fibonacci-c}
 \end{figure}
 
-
-Figure \ref{fig:fibonacci-cfa} is an example of a solution to the fibonnaci problem using \CFA coroutines, using the coroutine stack to hold sufficient state for the generation. This solution has the advantage of having very strong decoupling between how the sequence is generated and how it is used. Indeed, this version is a easy to use as the \code{fibonacci_state} solution, while the imlpementation is very similar to the \code{fibonacci_func} example.
+A good example of a problem made easier with coroutines is generators, like the fibonacci sequence. This problem comes with the challenge of decoupling how a sequence is generated and how it is used. Figure \ref{lst:fibonacci-c} shows conventional approaches to writing generators in C. All three of these approach suffer from strong coupling. The left and center approaches require that the generator have knowledge of how the sequence is used, while the rightmost approach requires holding internal state between calls on behalf of the generator and makes it much harder to handle corner cases like the Fibonacci seed.
+
+Figure \ref{lst:fibonacci-cfa} is an example of a solution to the fibonnaci problem using \CFA coroutines, where the coroutine stack holds sufficient state for the generation. This solution has the advantage of having very strong decoupling between how the sequence is generated and how it is used. Indeed, this version is as easy to use as the \code{fibonacci_state} solution, while the imlpementation is very similar to the \code{fibonacci_func} example.
 
 \begin{figure}
-\label{fig:fibonacci-cfa}
 \begin{cfacode}
 coroutine Fibonacci {
@@ -108,19 +148,19 @@
 
 //main automacically called on first resume
-void main(Fibonacci & this) {
+void main(Fibonacci & this) with (this) {
 	int fn1, fn2; 		//retained between resumes
-	this.fn = 0;
-	fn1 = this.fn;
+	fn  = 0;
+	fn1 = fn;
 	suspend(this); 		//return to last resume
 
-	this.fn = 1;
+	fn  = 1;
 	fn2 = fn1;
-	fn1 = this.fn;
+	fn1 = fn;
 	suspend(this); 		//return to last resume
 
 	for ( ;; ) {
-		this.fn = fn1 + fn2;
+		fn  = fn1 + fn2;
 		fn2 = fn1;
-		fn1 = this.fn;
+		fn1 = fn;
 		suspend(this); 	//return to last resume
 	}
@@ -140,63 +180,10 @@
 \end{cfacode}
 \caption{Implementation of fibonacci using coroutines}
+\label{lst:fibonacci-cfa}
 \end{figure}
 
-\subsection{Construction}
-One important design challenge for coroutines and threads (shown in section \ref{threads}) is that the runtime system needs to run code after the user-constructor runs to connect the object into the system. In the case of coroutines, this challenge is simpler since there is no non-determinism from preemption or scheduling. However, the underlying challenge remains the same for coroutines and threads.
-
-The runtime system needs to create the coroutine's stack and more importantly prepare it for the first resumption. The timing of the creation is non-trivial since users both expect to have fully constructed objects once execution enters the coroutine main and to be able to resume the coroutine from the constructor. As regular objects, constructors can leak coroutines before they are ready. There are several solutions to this problem but the chosen options effectively forces the design of the coroutine.
-
-Furthermore, \CFA faces an extra challenge as polymorphic routines create invisible thunks when casted to non-polymorphic routines and these thunks have function scope. For example, the following code, while looking benign, can run into undefined behaviour because of thunks:
-
-\begin{cfacode}
-//async: Runs function asynchronously on another thread
-forall(otype T)
-extern void async(void (*func)(T*), T* obj);
-
-forall(otype T)
-void noop(T *) {}
-
-void bar() {
-	int a;
-	async(noop, &a);
-}
-\end{cfacode}
-
-The generated C code\footnote{Code trimmed down for brevity} creates a local thunk to hold type information:
-
-\begin{ccode}
-extern void async(/* omitted */, void (*func)(void *), void *obj);
-
-void noop(/* omitted */, void *obj){}
-
-void bar(){
-	int a;
-	void _thunk0(int *_p0){
-		/* omitted */
-		noop(/* omitted */, _p0);
-	}
-	/* omitted */
-	async(/* omitted */, ((void (*)(void *))(&_thunk0)), (&a));
-}
-\end{ccode}
-The problem in this example is a storage management issue, the function pointer \code{_thunk0} is only valid until the end of the block. This extra challenge limits which solutions are viable because storing the function pointer for too long causes undefined behavior; i.e. the stack based thunk being destroyed before it was used. This challenge is an extension of challenges that come with second-class routines. Indeed, GCC nested routines also have the limitation that the routines cannot be passed outside of the scope of the functions these were declared in. The case of coroutines and threads is simply an extension of this problem to multiple call-stacks.
-
-\subsection{Alternative: Composition}
-One solution to this challenge is to use composition/containement, where uses add insert a coroutine field which contains the necessary information to manage the coroutine.
-
-\begin{cfacode}
-struct Fibonacci {
-	int fn; //used for communication
-	coroutine c; //composition
-};
-
-void ?{}(Fibonacci & this) {
-	this.fn = 0;
-	(this.c){}; //Call constructor to initialize coroutine
-}
-\end{cfacode}
-There are two downsides to this approach. The first, which is relatively minor, made aware of the main routine pointer. This information must either be store in the coroutine runtime data or in its static type structure. When using composition, all coroutine handles have the same static type structure which means the pointer to the main needs to be part of the runtime data. This requirement means the coroutine data must be made larger to store a value that is actually a compile time constant (address of the main routine). The second problem, which is both subtle and significant, is that now users can get the initialisation order of coroutines wrong. Indeed, every field of a \CFA struct is constructed but in declaration order, unless users explicitly write otherwise. This semantics means that users who forget to initialize the coroutine handle may resume the coroutine with an uninitilized object. For coroutines, this is unlikely to be a problem, for threads however, this is a significant problem. Figure \ref{fig:fmt-line} shows the \code{Format} coroutine which rearranges text in order to group characters into blocks of fixed size. This is a good example where the control flow is made much simpler from being able to resume the coroutine from the constructor and highlights the idea that interesting control flow can occor in the constructor.
+Figure \ref{lst:fmt-line} shows the \code{Format} coroutine which rearranges text in order to group characters into blocks of fixed size. The example takes advantage of resuming coroutines in the constructor to simplify the code and highlights the idea that interesting control flow can occur in the constructor.
+
 \begin{figure}
-\label{fig:fmt-line}
 \begin{cfacode}[tabsize=3]
 //format characters into blocks of 4 and groups of 5 blocks per line
@@ -244,6 +231,67 @@
 \end{cfacode}
 \caption{Formatting text into lines of 5 blocks of 4 characters.}
+\label{lst:fmt-line}
 \end{figure}
 
+\subsection{Construction}
+One important design challenge for coroutines and threads (shown in section \ref{threads}) is that the runtime system needs to run code after the user-constructor runs to connect the fully constructed object into the system. In the case of coroutines, this challenge is simpler since there is no non-determinism from preemption or scheduling. However, the underlying challenge remains the same for coroutines and threads.
+
+The runtime system needs to create the coroutine's stack and more importantly prepare it for the first resumption. The timing of the creation is non-trivial since users both expect to have fully constructed objects once execution enters the coroutine main and to be able to resume the coroutine from the constructor. As regular objects, constructors can leak coroutines before they are ready. There are several solutions to this problem but the chosen options effectively forces the design of the coroutine.
+
+Furthermore, \CFA faces an extra challenge as polymorphic routines create invisible thunks when casted to non-polymorphic routines and these thunks have function scope. For example, the following code, while looking benign, can run into undefined behaviour because of thunks:
+
+\begin{cfacode}
+//async: Runs function asynchronously on another thread
+forall(otype T)
+extern void async(void (*func)(T*), T* obj);
+
+forall(otype T)
+void noop(T*) {}
+
+void bar() {
+	int a;
+	async(noop, &a); //start thread running noop with argument a
+}
+\end{cfacode}
+
+The generated C code\footnote{Code trimmed down for brevity} creates a local thunk to hold type information:
+
+\begin{ccode}
+extern void async(/* omitted */, void (*func)(void *), void *obj);
+
+void noop(/* omitted */, void *obj){}
+
+void bar(){
+	int a;
+	void _thunk0(int *_p0){
+		/* omitted */
+		noop(/* omitted */, _p0);
+	}
+	/* omitted */
+	async(/* omitted */, ((void (*)(void *))(&_thunk0)), (&a));
+}
+\end{ccode}
+The problem in this example is a storage management issue, the function pointer \code{_thunk0} is only valid until the end of the block, which limits the viable solutions because storing the function pointer for too long causes undefined behavior; i.e., the stack-based thunk being destroyed before it can be used. This challenge is an extension of challenges that come with second-class routines. Indeed, GCC nested routines also have the limitation that nested routine cannot be passed outside of the declaration scope. The case of coroutines and threads is simply an extension of this problem to multiple call-stacks.
+
+\subsection{Alternative: Composition}
+One solution to this challenge is to use composition/containement, where coroutine fields are added to manage the coroutine.
+
+\begin{cfacode}
+struct Fibonacci {
+	int fn; //used for communication
+	coroutine c; //composition
+};
+
+void FibMain(void *) {
+	//...
+}
+
+void ?{}(Fibonacci & this) {
+	this.fn = 0;
+	//Call constructor to initialize coroutine
+	(this.c){myMain};
+}
+\end{cfacode}
+The downside of this approach is that users need to correctly construct the coroutine handle before using it. Like any other objects, doing so the users carefully choose construction order to prevent usage of unconstructed objects. However, in the case of coroutines, users must also pass to the coroutine information about the coroutine main, like in the previous example. This opens the door for user errors and requires extra runtime storage to pass at runtime information that can be known statically.
 
 \subsection{Alternative: Reserved keyword}
@@ -255,5 +303,5 @@
 };
 \end{cfacode}
-This mean the compiler can solve problems by injecting code where needed. The downside of this approach is that it makes coroutine a special case in the language. Users who would want to extend coroutines or build their own for various reasons can only do so in ways offered by the language. Furthermore, implementing coroutines without language supports also displays the power of the programming language used. While this is ultimately the option used for idiomatic \CFA code, coroutines and threads can both be constructed by users without using the language support. The reserved keywords are only present to improve ease of use for the common cases.
+The \code{coroutine} keyword means the compiler can find and inject code where needed. The downside of this approach is that it makes coroutine a special case in the language. Users wantint to extend coroutines or build their own for various reasons can only do so in ways offered by the language. Furthermore, implementing coroutines without language supports also displays the power of the programming language used. While this is ultimately the option used for idiomatic \CFA code, coroutines and threads can still be constructed by users without using the language support. The reserved keywords are only present to improve ease of use for the common cases.
 
 \subsection{Alternative: Lamda Objects}
@@ -268,5 +316,5 @@
 Often, the canonical threading paradigm in languages is based on function pointers, pthread being one of the most well known examples. The main problem of this approach is that the thread usage is limited to a generic handle that must otherwise be wrapped in a custom type. Since the custom type is simple to write in \CFA and solves several issues, added support for routine/lambda based coroutines adds very little.
 
-A variation of this would be to use an simple function pointer in the same way pthread does for threads :
+A variation of this would be to use a simple function pointer in the same way pthread does for threads :
 \begin{cfacode}
 void foo( coroutine_t cid, void * arg ) {
@@ -281,5 +329,5 @@
 }
 \end{cfacode}
-This semantic is more common for thread interfaces than coroutines but would work equally well. As discussed in section \ref{threads}, this approach is superseeded by static approaches in terms of expressivity.
+This semantics is more common for thread interfaces than coroutines works equally well. As discussed in section \ref{threads}, this approach is superseeded by static approaches in terms of expressivity.
 
 \subsection{Alternative: Trait-based coroutines}
@@ -350,5 +398,5 @@
 \end{cfacode}
 
-In this example, threads of type \code{foo} start execution in the \code{void main(foo &)} routine, which prints \code{"Hello World!"}. While this thesis encourages this approach to enforce strongly-typed programming, users may prefer to use the routine-based thread semantics for the sake of simplicity. With these semantics it is trivial to write a thread type that takes a function pointer as a parameter and executes it on its stack asynchronously
+In this example, threads of type \code{foo} start execution in the \code{void main(foo &)} routine, which prints \code{"Hello World!"}. While this thesis encourages this approach to enforce strongly-typed programming, users may prefer to use the routine-based thread semantics for the sake of simplicity. With the static semantics it is trivial to write a thread type that takes a function pointer as a parameter and executes it on its stack asynchronously.
 \begin{cfacode}
 typedef void (*voidFunc)(int);
@@ -361,12 +409,14 @@
 void ?{}(FuncRunner & this, voidFunc inFunc, int arg) {
 	this.func = inFunc;
+	this.arg  = arg;
 }
 
 void main(FuncRunner & this) {
+	//thread starts here and runs the function
 	this.func( this.arg );
 }
 \end{cfacode}
 
-An consequence of the strongly typed approach to main is that memory layout of parameters and return values to/from a thread are now explicitly specified in the \acrshort{api}.
+A consequence of the strongly-typed approach to main is that memory layout of parameters and return values to/from a thread are now explicitly specified in the \acrshort{api}.
 
 Of course for threads to be useful, it must be possible to start and stop threads and wait for them to complete execution. While using an \acrshort{api} such as \code{fork} and \code{join} is relatively common in the literature, such an interface is unnecessary. Indeed, the simplest approach is to use \acrshort{raii} principles and have threads \code{fork} after the constructor has completed and \code{join} before the destructor runs.
@@ -389,5 +439,5 @@
 \end{cfacode}
 
-This semantic has several advantages over explicit semantics: a thread is always started and stopped exaclty once and users cannot make any progamming errors and it naturally scales to multiple threads meaning basic synchronisation is very simple
+This semantic has several advantages over explicit semantics: a thread is always started and stopped exaclty once, users cannot make any progamming errors, and it naturally scales to multiple threads meaning basic synchronisation is very simple.
 
 \begin{cfacode}
@@ -411,5 +461,5 @@
 \end{cfacode}
 
-However, one of the drawbacks of this approach is that threads now always form a lattice, that is they are always destroyed in opposite order of construction because of block structure. This restriction is relaxed by using dynamic allocation, so threads can outlive the scope in which they are created, much like dynamically allocating memory lets objects outlive the scope in which they are created
+However, one of the drawbacks of this approach is that threads now always form a lattice, that is they are always destroyed in the opposite order of construction because of block structure. This restriction is relaxed by using dynamic allocation, so threads can outlive the scope in which they are created, much like dynamically allocating memory lets objects outlive the scope in which they are created.
 
 \begin{cfacode}
Index: doc/proposals/concurrency/text/cforall.tex
===================================================================
--- doc/proposals/concurrency/text/cforall.tex	(revision 64b272aedd6db65f570acb3d386065b1438f00f8)
+++ doc/proposals/concurrency/text/cforall.tex	(revision a2ea829dc9b8ad1d478141b95be3b1e4b558d102)
@@ -7,12 +7,13 @@
 The following is a quick introduction to the \CFA language, specifically tailored to the features needed to support concurrency.
 
-\CFA is a extension of ISO-C and therefore supports all of the same paradigms as C. It is a non-object oriented system language, meaning most of the major abstractions have either no runtime overhead or can be opt-out easily. Like C, the basics of \CFA revolve around structures and routines, which are thin abstractions over machine code. The vast majority of the code produced by the \CFA translator respects memory-layouts and calling-conventions laid out by C. Interestingly, while \CFA is not an object-oriented language, lacking the concept of a receiver (e.g., this), it does have some notion of objects\footnote{C defines the term objects as : [Where to I get the C11 reference manual?]}, most importantly construction and destruction of objects. Most of the following code examples can be found on the \CFA website \cite{www-cfa}
+\CFA is a extension of ISO-C and therefore supports all of the same paradigms as C. It is a non-object oriented system language, meaning most of the major abstractions have either no runtime overhead or can be opt-out easily. Like C, the basics of \CFA revolve around structures and routines, which are thin abstractions over machine code. The vast majority of the code produced by the \CFA translator respects memory-layouts and calling-conventions laid out by C. Interestingly, while \CFA is not an object-oriented language, lacking the concept of a receiver (e.g., this), it does have some notion of objects\footnote{C defines the term objects as : ``region of data storage in the execution environment, the contents of which can represent
+values''\cite[3.15]{C11}}, most importantly construction and destruction of objects. Most of the following code examples can be found on the \CFA website \cite{www-cfa}
 
 \section{References}
 
-Like \CC, \CFA introduces references as an alternative to pointers. In regards to concurrency, the semantics difference between pointers and references are not particularly relevant but since this document uses mostly references here is a quick overview of the semantics :
+Like \CC, \CFA introduces rebindable references providing multiple dereferecing as an alternative to pointers. In regards to concurrency, the semantic difference between pointers and references are not particularly relevant, but since this document uses mostly references, here is a quick overview of the semantics:
 \begin{cfacode}
 int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
-&r1 = x,    &&r2 = r1,   &&&r3 = r2;
+	&r1 = x,    &&r2 = r1,   &&&r3 = r2;
 ***p3 = 3;							//change x
 r3    = 3;							//change x, ***r3
@@ -25,9 +26,9 @@
 sizeof(&ar[1]) == sizeof(int *);	//is true, i.e., the size of a reference
 \end{cfacode}
-The important thing to take away from this code snippet is that references offer a handle to an object much like pointers but which is automatically derefferenced when convinient.
+The important take away from this code example is that references offer a handle to an object, much like pointers, but which is automatically dereferenced for convinience.
 
 \section{Overloading}
 
-Another important feature of \CFA is function overloading as in Java and \CC, where routine with the same name are selected based on the numbers and type of the arguments. As well, \CFA uses the return type as part of the selection criteria, as in Ada\cite{Ada}. For routines with multiple parameters and returns, the selection is complex.
+Another important feature of \CFA is function overloading as in Java and \CC, where routines with the same name are selected based on the number and type of the arguments. As well, \CFA uses the return type as part of the selection criteria, as in Ada\cite{Ada}. For routines with multiple parameters and returns, the selection is complex.
 \begin{cfacode}
 //selection based on type and number of parameters
@@ -45,8 +46,8 @@
 double d = f(4);		//select (2)
 \end{cfacode}
-This feature is particularly important for concurrency since the runtime system relies on creating different types to represent concurrency objects. Therefore, overloading is necessary to prevent the need for long prefixes and other naming conventions that prevent name clashes. As seen in chapter \ref{basics}, routines main is an example that benefits from overloading.
+This feature is particularly important for concurrency since the runtime system relies on creating different types to represent concurrency objects. Therefore, overloading is necessary to prevent the need for long prefixes and other naming conventions that prevent name clashes. As seen in chapter \ref{basics}, routine \code{main} is an example that benefits from overloading.
 
 \section{Operators}
-Overloading also extends to operators. The syntax for denoting operator-overloading is to name a routine with the symbol of the operator and question marks where the arguments of the operation would be, like so :
+Overloading also extends to operators. The syntax for denoting operator-overloading is to name a routine with the symbol of the operator and question marks where the arguments of the operation occur, e.g.:
 \begin{cfacode}
 int ++? (int op);              		//unary prefix increment
@@ -101,5 +102,5 @@
 
 \section{Parametric Polymorphism}
-Routines in \CFA can also be reused for multiple types. This is done using the \code{forall} clause which gives \CFA it's name. \code{forall} clauses allow seperatly compiled routines to support generic usage over multiple types. For example, the following sum function will work for any type which support construction from 0 and addition :
+Routines in \CFA can also be reused for multiple types. This capability is done using the \code{forall} clause which gives \CFA its name. \code{forall} clauses allow separately compiled routines to support generic usage over multiple types. For example, the following sum function works for any type that supports construction from 0 and addition :
 \begin{cfacode}
 //constraint type, 0 and +
@@ -116,5 +117,5 @@
 \end{cfacode}
 
-Since writing constraints on types can become cumbersome for more constrained functions, \CFA also has the concept of traits. Traits are named collection of constraints which can be used both instead and in addition to regular constraints:
+Since writing constraints on types can become cumbersome for more constrained functions, \CFA also has the concept of traits. Traits are named collection of constraints that can be used both instead and in addition to regular constraints:
 \begin{cfacode}
 trait sumable( otype T ) {
@@ -130,8 +131,8 @@
 
 \section{with Clause/Statement}
-Since \CFA lacks the concept of a receiver, certain functions end-up needing to repeat variable names often, to solve this \CFA offers the \code{with} statement which opens an aggregate scope making its fields directly accessible (like Pascal).
+Since \CFA lacks the concept of a receiver, certain functions end-up needing to repeat variable names often. To remove this inconvenience, \CFA provides the \code{with} statement, which opens an aggregate scope making its fields directly accessible (like Pascal).
 \begin{cfacode}
 struct S { int i, j; };
-int mem(S & this) with this		//with clause
+int mem(S & this) with (this)		//with clause
 	i = 1;						//this->i
 	j = 2;						//this->j
@@ -140,9 +141,9 @@
 	struct S1 { ... } s1;
 	struct S2 { ... } s2;
-	with s1 					//with statement
+	with (s1) 					//with statement
 	{
 		//access fields of s1
 		//without qualification
-		with s2					//nesting
+		with (s2)					//nesting
 		{
 			//access fields of s1 and s2
@@ -150,5 +151,5 @@
 		}
 	}
-	with s1, s2 				//scopes open in parallel
+	with (s1, s2) 				//scopes open in parallel
 	{
 		//access fields of s1 and s2
Index: doc/proposals/concurrency/text/intro.tex
===================================================================
--- doc/proposals/concurrency/text/intro.tex	(revision 64b272aedd6db65f570acb3d386065b1438f00f8)
+++ doc/proposals/concurrency/text/intro.tex	(revision a2ea829dc9b8ad1d478141b95be3b1e4b558d102)
@@ -3,5 +3,5 @@
 % ======================================================================
 
-This thesis provides a minimal concurrency \acrshort{api} that is simple, efficient and can be reused to build higher-level features. The simplest possible concurrency system is a thread and a lock but this low-level approach is hard to master. An easier approach for users is to support higher-level constructs as the basis of concurrency. Indeed, for highly productive concurrent programming, high-level approaches are much more popular~\cite{HPP:Study}. Examples are task based, message passing and implicit threading. The high-level approach and its minimal \acrshort{api} are tested in a dialect of C, call \CFA. [Is there value to say that this thesis is also an early definition of the \CFA language and library in regards to concurrency?]
+This thesis provides a minimal concurrency \acrshort{api} that is simple, efficient and can be reused to build higher-level features. The simplest possible concurrency system is a thread and a lock but this low-level approach is hard to master. An easier approach for users is to support higher-level constructs as the basis of concurrency. Indeed, for highly productive concurrent programming, high-level approaches are much more popular~\cite{HPP:Study}. Examples are task based, message passing and implicit threading. The high-level approach and its minimal \acrshort{api} are tested in a dialect of C, call \CFA. Furthermore, the proposed \acrshort{api} doubles as an early definition of the \CFA language and library. This thesis also comes with an implementation of the concurrency library for \CFA as well as all the required language features added to the source-to-source translator.
 
 There are actually two problems that need to be solved in the design of concurrency for a programming language: which concurrency and which parallelism tools are available to the programmer. While these two concepts are often combined, they are in fact distinct, requiring different tools~\cite{Buhr05a}. Concurrency tools need to handle mutual exclusion and synchronization, while parallelism tools are about performance, cost and resource utilization.
Index: doc/proposals/concurrency/version
===================================================================
--- doc/proposals/concurrency/version	(revision 64b272aedd6db65f570acb3d386065b1438f00f8)
+++ doc/proposals/concurrency/version	(revision a2ea829dc9b8ad1d478141b95be3b1e4b558d102)
@@ -1,1 +1,1 @@
-0.10.340
+0.11.19