X-Git-Url: https://git.stderr.nl/gitweb?a=blobdiff_plain;f=Report%2FMain%2FFuture.tex;h=bfa737accb7e30a22689615182c1722cbfaf188d;hb=0ac3f8b7cfb60e71b9f95dc8bf1752e1e971685f;hp=3246baba351fe8d58ca9987fb3383175fb5a855e;hpb=8a551a00909d1d76971fbd86fcb4e3cf3948c214;p=matthijs%2Fprojects%2Finternship.git

diff --git a/Report/Main/Future.tex b/Report/Main/Future.tex
index 3246bab..bfa737a 100644
--- a/Report/Main/Future.tex
+++ b/Report/Main/Future.tex
@@ -1,6 +1,7 @@
 \chapter{Future work}
 \label{FutureWork}
-This chapter will describe outstanding tasks and issues.
+This chapter will describe tasks for the future and issues that remain
+to be resolved.
 
 \section{Verifiers}
 Currently, when faulty MontiumC is written, this will be detected very late in
@@ -32,8 +33,8 @@ more invasive changes to LLVM.
 
 These changes are generic for LLVM and not needed specifically for the Montium.
 Currently, most MontiumC code seems to still work with only a little
-change to LLVM, but especially with the new hardware, some missed out
-optimizations might become more useful.
+change to LLVM, but especially with the new hardware, these missed
+optimizations might become more of problem.
 
 \section{LLVM based backend}
 Currently, the frontend is using the LLVM framework, while the backend is
@@ -43,12 +44,12 @@ backend would benefit from being able to use existing LLVM code and passes,
 utility code, etc. Also, this would enable the compiler to become a single
 binary executable, instead of having a seperate executable and a Java program.
 
-However, the main risk here is when the LLVM framework turns out to be not fully
+However, the main risk here is that the LLVM framework might turn out to be not fully
 suitable for the Montium backend. When nothing can be reused, the amount of code
 needed is not any less, and if the framework poses limitations, might even be
-more. The new hardware design might be a lot more suitable for reusing code than
-the old Montium, though. Also, the added work of migrating to a new framework
-and new language is also a extra cost.
+more. The new hardware design might be a lot more suitable for reusing LLVM code than
+the old Montium, however. Also, the added work of migrating to a new framework
+and new language is also an extra cost.
 
 Currently, doing this might or might not be a good idea. What is required first,
 is doing a more in-depth investigation of the LLVM backend framework (which is,