Fix spelling as suggested by aspell.

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

diff --git a/Chapters/Future.tex b/Chapters/Future.tex
index 0399db9ba6d993ee7a76aa98f94cc3132c022d2a..523fc0a8a1a6d3313bb8354cb6e08e977159a993 100644 (file)
--- a/Chapters/Future.tex
+++ b/Chapters/Future.tex
@@ -71,7 +71,7 @@ no other ways that would work.
 
 One particular notation in Haskell that seems promising, is the \hs{do}
 notation. This is meant to simplify Monad notation by hiding away some
 
 One particular notation in Haskell that seems promising, is the \hs{do}
 notation. This is meant to simplify Monad notation by hiding away some

-details. It allows one to write a list of expressions, which are composited
+details. It allows one to write a list of expressions, which are composed

 using the monadic \emph{bind} operator, written in Haskell as \hs{>>}. For
 example, the snippet:
 
 using the monadic \emph{bind} operator, written in Haskell as \hs{>>}. For
 example, the snippet:
 


@@ -89,7 +89,7 @@ will be desugared into:
 
 The main reason to have the monadic notation, is to be able to wrap
 results of functions in a datatype (the \emph{monad}) that can contain
 
 The main reason to have the monadic notation, is to be able to wrap
 results of functions in a datatype (the \emph{monad}) that can contain

-extra information, and hide extra behaviour in the binding operators.
+extra information, and hide extra behavior in the binding operators.

 
 The \hs{>>=} operator allows extracting the actual result of a function
 and passing it to another function. The following snippet should
 
 The \hs{>>=} operator allows extracting the actual result of a function
 and passing it to another function. The following snippet should


@@ -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
 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}
 patterns, making our code smaller and easier to read.
 
 \subsection{Breaking out of the Monad}


@@ -161,7 +161,7 @@ means we can define our own \hs{>>} and \hs{>>=} operators, outside of the
 all of the Prelude) by passing \type{-XNoImplicitPrelude} to \type{ghc}. This
 is slightly inconvenient, but since we hardly using anything from the prelude,
 this is not a big problem. We might even be able to replace some of the
 all of the Prelude) by passing \type{-XNoImplicitPrelude} to \type{ghc}. This
 is slightly inconvenient, but since we hardly using anything from the prelude,
 this is not a big problem. We might even be able to replace some of the

-Prelude with hardware-translateable versions by doing this.
+Prelude with hardware-translatable versions by doing this.

 
 The binding operators can now be defined exactly as they are needed. For
 completeness, the \hs{return} function is also defined. It is not called
 
 The binding operators can now be defined exactly as they are needed. For
 completeness, the \hs{return} function is also defined. It is not called


@@ -185,7 +185,7 @@ return r = \s -> (s, r)
 
 These definitions closely resemble the boilerplate of unpacking state,
 passing it to two functions and repacking the new state. With these
 
 These definitions closely resemble the boilerplate of unpacking state,
 passing it to two functions and repacking the new state. With these

-definitions, we could have writting \in{example}[ex:NestedState] a lot
+definitions, we could have written \in{example}[ex:NestedState] a lot

 shorter, see \in{example}[ex:DoState]. In this example the type signature of
 foo is the same (though it is now written using the \hs{Stateful} type
 synonym, it is still completely equivalent to the original: \hs{foo :: Word ->
 shorter, see \in{example}[ex:DoState]. In this example the type signature of
 foo is the same (though it is now written using the \hs{Stateful} type
 synonym, it is still completely equivalent to the original: \hs{foo :: Word ->


@@ -217,7 +217,7 @@ function applications affects the state type. Fortunately, this problem can be
 localized by consistently using type synonyms for state types, which should
 prevent changes in other function's source when a function changes.
 
 localized by consistently using type synonyms for state types, which should
 prevent changes in other function's source when a function changes.
 

-A less obvous implications of this approach is that the scope of variables
+A less obvious implications of this approach is that the scope of variables

 produced by each of these expressions (using the \hs{<-} syntax) is limited to
 the expressions that come after it. This prevents values from flowing between
 two functions (components) in two directions. For most Monad instances, this
 produced by each of these expressions (using the \hs{<-} syntax) is limited to
 the expressions that come after it. This prevents values from flowing between
 two functions (components) in two directions. For most Monad instances, this


@@ -234,7 +234,7 @@ feasible.
 
 \subsection{Arrows}
 Another abstraction mechanism offered by Haskell are arrows. Arrows are
 
 \subsection{Arrows}
 Another abstraction mechanism offered by Haskell are arrows. Arrows are

-a generalisation of monads \cite[hughes98], for which \GHC also supports
+a generalization of monads \cite[hughes98], for which \GHC\ also supports

 some syntax sugar \cite[paterson01]. Their use for hiding away state
 boilerplate is not directly evident, but since arrows are a complex
 concept further investigation is appropriate.
 some syntax sugar \cite[paterson01]. Their use for hiding away state
 boilerplate is not directly evident, but since arrows are a complex
 concept further investigation is appropriate.


@@ -308,7 +308,7 @@ For this, there are two main problems to solve:
 
 \startitemize
 \item For list recursion, how to make a description type check? It is quite
 
 \startitemize
 \item For list recursion, how to make a description type check? It is quite

-possible that improvements in the \small{GHC} typechecker will make this
+possible that improvements in the \small{GHC} type-checker will make this

 possible, though it will still stay a challenge. Further advances in
 dependent typing support for Haskell will probably help here as well.
 
 possible, though it will still stay a challenge. Further advances in
 dependent typing support for Haskell will probably help here as well.
 


@@ -332,15 +332,15 @@ In a lot of real-world systems, both of these limitations pose problems.
 There might be asynchronous events to which a system wants to respond. The
 most obvious asynchronous event is of course a reset signal. Though a reset
 signal can be synchronous, that is less flexible (and a hassle to describe in
 There might be asynchronous events to which a system wants to respond. The
 most obvious asynchronous event is of course a reset signal. Though a reset
 signal can be synchronous, that is less flexible (and a hassle to describe in

-Cλash, currently). Since every function in Cλash describes the behaviour on
-each cycle boundary, we really cannot fit in asynchronous behaviour easily.
+Cλash, currently). Since every function in Cλash describes the behavior on
+each cycle boundary, we really cannot fit in asynchronous behavior easily.

 
 Due to the same reason, multiple clock domains cannot be easily supported. There is
 currently no way for the compiler to know in which clock domain a function
 should operate and since the clock signal is never explicit, there is also no
 way to express circuits that synchronize various clock domains.
 
 
 Due to the same reason, multiple clock domains cannot be easily supported. There is
 currently no way for the compiler to know in which clock domain a function
 should operate and since the clock signal is never explicit, there is also no
 way to express circuits that synchronize various clock domains.
 

-A possible way to express more complex timing behaviour would be to make
+A possible way to express more complex timing behavior would be to make

 functions more generic event handlers, where the system generates a stream of
 events (Like \quote{clock up}, \quote{clock down}, \quote{input A changed},
 \quote{reset}, etc.). When working with multiple clock domains, each domain
 functions more generic event handlers, where the system generates a stream of
 events (Like \quote{clock up}, \quote{clock down}, \quote{input A changed},
 \quote{reset}, etc.). When working with multiple clock domains, each domain


@@ -471,19 +471,19 @@ increasing the readability. As you might also have noted, the select\_clock
 function takes any stateful function from the current Cλash prototype and
 turns it into an event-aware function!
 
 function takes any stateful function from the current Cλash prototype and
 turns it into an event-aware function!
 

-Going along this route for more complex timing behaviour seems promising,
-espicially since it seems possible to express very advanced timing behaviours,
+Going along this route for more complex timing behavior seems promising,
+especially since it seems possible to express very advanced timing behaviors,

 while still allowing simple functions without any extra overhead when complex
 while still allowing simple functions without any extra overhead when complex

-behaviour is not needed.
+behavior is not needed.

 
 The main cost of this approach will probably be extra complexity in the
 
 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
 is probably hard to properly analyze these paths and produce the

-intended \VHDL description.
+intended \VHDL\ description.

 
 \section{Multiple cycle descriptions}
 In the current Cλash prototype, every description is a single-cycle
 
 \section{Multiple cycle descriptions}
 In the current Cλash prototype, every description is a single-cycle

-description. In other words, every function describes behaviour for each
+description. In other words, every function describes behavior for each

 separate cycle and any recursion (or folds, maps, etc.) is expanded in space.
 
 Sometimes, you might want to have a complex description that could possibly
 separate cycle and any recursion (or folds, maps, etc.) is expanded in space.
 
 Sometimes, you might want to have a complex description that could possibly


@@ -492,21 +492,21 @@ take multiple cycles. Some examples include:
 \startitemize
   \item Some kind of map or fold over a list that could be expanded in time
   instead of space. This would result in a function that describes n cycles
 \startitemize
   \item Some kind of map or fold over a list that could be expanded in time
   instead of space. This would result in a function that describes n cycles

-  instead of just one, where n is the lenght of the list.
+  instead of just one, where n is the length of the list.

   \item A large combinational expressions that would introduce a very long
   combinational path and thus limit clock frequency. Such an expression could
   be broken up into multiple stages, which effectively results in a pipelined
   system (see also \in{section}[sec:future:pipelining]) with a known delay.
   There should probably be some way for the developer to specify the cycle
   division of the expression, since automatically deciding on such a division
   \item A large combinational expressions that would introduce a very long
   combinational path and thus limit clock frequency. Such an expression could
   be broken up into multiple stages, which effectively results in a pipelined
   system (see also \in{section}[sec:future:pipelining]) with a known delay.
   There should probably be some way for the developer to specify the cycle
   division of the expression, since automatically deciding on such a division

-  is too complex and contains too many tradeoffs, at least initially.
+  is too complex and contains too many trade-offs, at least initially.

   \item Unbounded recursion. It is not possible to expand unbounded (or even
   recursion with a depth that is not known at compile time) in space, since
   there is no way to tell how much hardware to create (it might even be
   infinite).
 
   When expanding infinite recursion over time, each step of the recursion can
   \item Unbounded recursion. It is not possible to expand unbounded (or even
   recursion with a depth that is not known at compile time) in space, since
   there is no way to tell how much hardware to create (it might even be
   infinite).
 
   When expanding infinite recursion over time, each step of the recursion can

-  simply become a single clockcycle. When expanding bounded but unknown
+  simply become a single clock cycle. When expanding bounded but unknown

   recursion, we probably need to add an extra data valid output bit or
   something similar.
 \stopitemize
   recursion, we probably need to add an extra data valid output bit or
   something similar.
 \stopitemize


@@ -523,16 +523,16 @@ 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
 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
 purity properties. Making this function have some state input and output could
 help, though this state is not present in the actual hardware (or perhaps
 there is some state, if there are value passed from one recursion step to the
 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
 purity properties. Making this function have some state input and output could
 help, though this state is not present in the actual hardware (or perhaps
 there is some state, if there are value passed from one recursion step to the

-next, but how can the type of that state be determined by the typechecker?).
+next, but how can the type of that state be determined by the type-checker?).

 
 

-It seems that this is the most pressing problem for multicycle descriptions:
+It seems that this is the most pressing problem for multi-cycle descriptions:

 How to interface with the rest of the system, without sacrificing safety and
 simulation capabilities?
 
 How to interface with the rest of the system, without sacrificing safety and
 simulation capabilities?
 


@@ -587,17 +587,17 @@ higher-order value at the spot where it is applied, and thus the higher-order
 value disappears.
 
 This approach is commonly known as the \quote{Reynolds approach to
 value disappears.
 
 This approach is commonly known as the \quote{Reynolds approach to

-defuntionalization}, first described by J.C. Reynolds \cite[reynolds98] and
+defunctionalization}, first described by J.C. Reynolds \cite[reynolds98]\ and

 seems to apply well to this situation. One note here is that Reynolds'
 approach puts all the higher-order values in a single datatype. For a typed
 language, we will at least have to have a single datatype for each function
 type, since we cannot mix them. It would be even better to split these
 seems to apply well to this situation. One note here is that Reynolds'
 approach puts all the higher-order values in a single datatype. For a typed
 language, we will at least have to have a single datatype for each function
 type, since we cannot mix them. It would be even better to split these

-datatypes a bit further, so that such a datatype will never hold a constructor
+data-types a bit further, so that such a datatype will never hold a constructor

 that is never used for a particular state variable. This separation is
 probably a non-trivial problem, though.
 
 \section{Don't care values}
 that is never used for a particular state variable. This separation is
 probably a non-trivial problem, though.
 
 \section{Don't care values}

-  A powerful value in \VHDL is the \emph{don't care} value, given as
+  A powerful value in \VHDL\ is the \emph{don't care} value, given as

   \type{'-'}. This value tells the compiler that you do not really care about
   which value is assigned to a signal, allowing the compiler to make some
   optimizations. Since choice in hardware is often implemented using
   \type{'-'}. This value tells the compiler that you do not really care about
   which value is assigned to a signal, allowing the compiler to make some
   optimizations. Since choice in hardware is often implemented using


@@ -622,7 +622,7 @@ probably a non-trivial problem, though.
     This would also require some kind of \quote{Don't careable} type class
     that allows each type to specify what its don't care value is. The
     compiler must then recognize this constant and replace it with don't care
     This would also require some kind of \quote{Don't careable} type class
     that allows each type to specify what its don't care value is. The
     compiler must then recognize this constant and replace it with don't care

-    values in the final \VHDL code.
+    values in the final \VHDL\ code.

 
     This is of course a very intrusive solution. Every type must become member
     of this type class, and there is now some member in every type that is a
 
     This is of course a very intrusive solution. Every type must become member
     of this type class, and there is now some member in every type that is a


@@ -660,7 +660,7 @@ probably a non-trivial problem, though.
     value should always return a Low value. Its value does not depend on the
     value chosen for the don't care value. However, though when applying the
     above and function to \hs{Low} and \hs{undefined} results in exactly that
     value should always return a Low value. Its value does not depend on the
     value chosen for the don't care value. However, though when applying the
     above and function to \hs{Low} and \hs{undefined} results in exactly that

-    behviour, the result is \hs{undefined} when the arguments are swapped.
+    behavior, the result is \hs{undefined} when the arguments are swapped.

     This is because the first pattern forces the first argument to be
     evaluated. If it is \hs{undefined}, evaluation is halted and an exception
     is show, which is not what is intended.
     This is because the first pattern forces the first argument to be
     evaluated. If it is \hs{undefined}, evaluation is halted and an exception
     is show, which is not what is intended.