Use η/β-expansion instead of η/β-abstraction.

[matthijs/master-project/report.git] / Chapters / Future.tex

diff --git a/Chapters/Future.tex b/Chapters/Future.tex
index da1b23de211aa3ba3a8ba066b3e620ee40393e4a..d395586754892afbfc0539fb2da846a6975a2bd5 100644 (file)
--- a/Chapters/Future.tex
+++ b/Chapters/Future.tex
@@ -123,7 +123,7 @@ these descriptions without any special magic (though perhaps it should
 always inline the binding operators to reveal the flow of values).
 
 This highlights an important aspect of using a functional language for our
-descriptions: We can use the language itself to provide abstractions of common
+descriptions: we can use the language itself to provide abstractions of common
 patterns, making our code smaller and easier to read.
 
 \subsection{Breaking out of the Monad}
@@ -477,7 +477,7 @@ while still allowing simple functions without any extra overhead when complex
 behaviour is not needed.
 
 The main cost of this approach will probably be extra complexity in the
-compiler: The paths (state) data can take become very non-trivial, and it
+compiler: the paths (state) data can take become very non-trivial, and it
 is probably hard to properly analyze these paths and produce the
 intended \VHDL\ description.
 
@@ -523,7 +523,7 @@ generates just a single element each cycle).
 Naively, this matching could be done using a (built-in) function with a
 signature like \lam{[a] -> a}, which also serves as an indicator to the
 compiler that some expanding over time is required. However, this poses a
-problem for simulation: How will our Haskell implementation of this magical
+problem for simulation: how will our Haskell implementation of this magical
 built-in function know which element of the input list to return. This
 obviously depends on the current cycle number, but there is no way for this
 function to know the current cycle without breaking all kinds of safety and