--- a/paper/Makefile	Fri Jun 15 20:12:37 2012 +0900
+++ b/paper/Makefile	Fri Jun 15 20:49:20 2012 +0900
@@ -1,6 +1,6 @@
-DEPENDENCY = rectype.ind graphics[width=6cm]figure/code.pdf graphicsfigure/tree1.pdf graphicsfigure/tree2.pdf
+DEPENDENCY = rectype.ind figure/code.pdf figure/tree1.pdf figure/tree2.pdf
 
-DEPENDOHP = ohp.tex graphics[width=6cm]figure/code.pdf graphicsfigure/tree1.pdf graphicsfigure/tree2.pdf
+DEPENDOHP = ohp.tex figure/code.pdf figure/tree1.pdf figure/tree2.pdf
 
 PAPER = rectype.ind
 

--- a/paper/rectype.ind	Fri Jun 15 20:12:37 2012 +0900
+++ b/paper/rectype.ind	Fri Jun 15 20:49:20 2012 +0900
@@ -20,7 +20,7 @@
 
 --Continuation based C
 
-CbC's basic programming unit is a code segment. It is not a subroutine, but it
+CbC's basic programming unit is a Code Segment. It is not a subroutine, but it
 looks like a function, because it has input and output. We can use C struct
 as input and output interfaces.
 
@@ -32,13 +32,13 @@
        goto g(b); 
    }
 
-In this example, a code segment
-\verb+f+ has \verb+input a+ and sends \verb+output b+ to a code segment \verb+g+.
-There is no return from code segment \verb+b+, \verb+b+ should call another
+In this example, a Code Segment
+\verb+f+ has \verb+input a+ and sends \verb+output b+ to a Code Segment \verb+g+.
+There is no return from Code Segment \verb+b+, \verb+b+ should call another
 continuation using \verb+goto+. Any control structure in C is allowed in CwC
 language, but in case of CbC, we restrict ourselves to use \verb+if+ statement
 only, because it is sufficient to implement C to CbC translation. In this case,
-code segment has one input interface and several output interfaces (fig.\ref{code}).
+Code Segment has one input interface and several output interfaces (fig.\ref{code}).
 
 \begin{figure}[htb]
 \begin{center}
@@ -55,8 +55,8 @@
 
 --Intermix with C
 
-In CwC, we can go to a code segment from a C function and we can call C functions
-in a code segment. So we don't have to shift completely from C to CbC. The later
+In CwC, we can go to a Code Segment from a C function and we can call C functions
+in a Code Segment. So we don't have to shift completely from C to CbC. The later
 one is straight forward, but the former one needs further extensions.
 
    void *env;
@@ -76,7 +76,7 @@
 In this hello world example, the environment of \verb+main()+
 and its continuation is kept in global variables. The environment
 and the continuation can be get using \verb+__environment+,
-and \verb+__return+. Arbitrary mixture of code segments and functions
+and \verb+__return+. Arbitrary mixture of Code Segments and functions
 are allowed (in CwC). The continuation of \verb+goto+ statement 
 never returns to original function, but it goes to caller of original
 function. In this case, it returns result 0 to the operating system.
@@ -176,14 +176,14 @@
 
 --Recursive type syntax
 
-CbC's program pass next pointer of code segment on argument.
+CbC's program pass next pointer of Code Segment on argument.
 It is passed as follows.
 
    __code csA( __code (*p)() ) {
        goto p(csB);
    }
 
-p is next pointer of codesegment.
+p is next pointer of Code Segment.
 But, This declarationd is not right.
 Because p have arguments.
 We wanted to the same type of p's arguments as type of csA's arguments.
@@ -258,7 +258,7 @@
 
 The above code is the wrong argument of p.
 The p's argument is converted by GCC.
-3 of type int is converted to a pionter type of code segment.
+3 of type int is converted to a pionter type of Code Segment.
 At this time, GCC looks at the type of the argument.
 p's argument is pointer of csA.
 csA's argument is p.
@@ -316,7 +316,7 @@
 
 there is no need to write recursively.
 Because the struct syntax wrapped in a function pointer.
-Code segment does not receive function pointer in arguments.
+Code Segment does not receive function pointer in arguments.
 Recursively program does not occur.
 
 
@@ -366,8 +366,10 @@
 
     __code print(__code (*p)(__code(*)(),long int,long int,long int,long int),
                   long int num, long int count, long int result, long int prev);
+
     __code fibonacci(__code (*p)(__code(*)(),long int,long int, long int,long int),
                      long int num,  long int count, long int result, long int prev);
+
     __code cs_while(__code (*p)(__code(*)(),long int, long int, long int, long int),
                      long int num, long int count, long int result, long int prev);
 
@@ -381,26 +383,24 @@
 \centering
 \small
 \begin{tabular}{|l|r|r|r|} \hline
-(unit: s) & ./fibonacci 1000 \\ \hline
+                    & 10000 \\ \hline
 using rectype       & 0.7  \\ \hline
 not use rectype       & 0.7 \\ \hline
 \end{tabular}
-\caption{GCC bench mark (in sec)}
+\caption{bench mark (in sec)}
 \label{tab:gcc,compare}
 \end{table}
 
 There was no difference in the results are as we predicted.
 
 
-
 --Conclusion
 
 We have designed and implemented Continuation based language for practical use.
-We have implemented \rectype syntax.
-Thereby Easily be able to write code than previous.
+We have implemented \rectype syntax in GCC for CbC.
+Thereby Easily be able to write CbC program than previous.
+
+This \rectype implementation may be other problems.
+If so, it is necessary to find and fix them on future.
 
 
-
-
-
-