Binary file Paper/master_paper.pdf has changed

--- a/Paper/master_paper.tex	Wed Feb 07 17:39:37 2024 +0900
+++ b/Paper/master_paper.tex	Wed Feb 07 17:47:20 2024 +0900
@@ -801,8 +801,8 @@
 このようにして，条件分岐をして実行するCodeGearを切り替えることができる．
 しかし，GCは本来行いたい処理ではなくメタレベルの処理である．
 そのため，GCへの切り替えにおいてソースコード\ref{src:isEmpty.cbc}のようなコードを記述すると，
-ノーマルレベルとメタレベルが混在するCodeGearとなってしまう問題がある．
-これは，GC処理を自動的に
+ノーマルレベルとメタレベルが混在するCodeGearとなる問題がある．
+これは，GC処理を自動的に % TODO
 
 \section{別Contextへのコピー}
 
@@ -823,7 +823,7 @@
 
 RedBlackTreeは別のContextへコピーすると良い．
 同じContextへコピーする場合，GCはFromとToの領域が同じヒープ領域に置かれることになる．
-ヒープ領域を共有してしまうと，FromからToへの切り替えがしづらい．
+ヒープ領域を共有すると，FromからToへの切り替えがしづらい．
 また，すでにそのヒープ領域でフラグメンテーションが起きている可能性があり，
 Copying GCの利点であるコンパクションができない．
 レプリケーションの場合，別のノードでは別のContextが動いているため，
@@ -839,7 +839,7 @@
 RedBlackTreeは非破壊であり，複数のルートノードによってバージョン管理されている．
 そのため，あるバージョンのバックアップをリストアしたい場合がある．
 現在のバージョンをディスク上にある特定のバージョンに切り替える場合，
-現在のバージョンへの書き込みの最中にバージョンが切り替わってしまうとデータの一貫性を損なう．
+現在のバージョンへの書き込みの最中にバージョンが切り替わるとデータの一貫性を損なう．
 そのため，データリストア時の一貫性を確保する仕組みが必要となる．
 また，バージョン付きのバックアップは無尽蔵にデータが増加していく問題がある．
 それは，任意のタイミングでデータを区切ることで解決できる．
@@ -1017,7 +1017,7 @@
 
 今回の実装ではSingleLinkedStackを2つ使用している．
 CbCはcall stackなどの状態を持たないことによる利点があるため，
-Stackを使用することによってその利点を得られなくなってしまうことが考えられる．
+Stackを使用することによってその利点を得られなくなることが考えられる．
 しかしながら，今回のStackはCall stackとは違い，プログラムの中で明示的に使用され，
 また，CodeGear自体が状態を持たないため問題がない．