X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FConclusions.tex;h=7e76abc4eca6c5a79b28687dfbcae784af49e651;hp=c12e99d0665c6d3f172573f86993804c5670bca3;hb=58a5aa7ca5edc07ba1070f4f4ed384b42e36e8f3;hpb=901c9881c60ac1897aa8efb63d082798272e1ae7

diff --git a/Chapters/Conclusions.tex b/Chapters/Conclusions.tex
index c12e99d..7e76abc 100644
--- a/Chapters/Conclusions.tex
+++ b/Chapters/Conclusions.tex
@@ -1,7 +1,7 @@
 \chapter[chap:conclusions]{Conclusions}
-At the end of this research, we have created a system called Cλash, which
-allows us to translate hardware descriptions written in Haskell to be
-translated to \VHDL, and be programmed into an FPGA.
+The product of this research is a system called Cλash, which allows hardware
+descriptions written in Haskell to be translated to \VHDL and be programmed
+into an \small{FPGA}.
 
 In this research, we have seen that a functional language is well suited
 for hardware descriptions. Function applications provide elegant notation for
@@ -9,30 +9,81 @@ component instantiation and the various choice mechanisms (pattern matching,
 case expressions, if expressions) are well suited to describe conditional
 assigment in the hardware.
 
-Useful features from the functional perspective, like polymorphism and higher
-order functions and expressions are also well-suited for translation to
-hardware.
+Useful features from the functional perspective, like polymorphism and
+higher-order functions and expressions also prove suitable to describe
+hardware and our implementation shows that they can be translated to
+\VHDL\ as well.
 
-Using Haskell enabled a rapid prototype supporting complex features like
-polymorphism and higher order values. Mostly typechecker would have been
-complicated otherwise.
+A prototype compiler was created in this research. For this prototype the
+Haskell language was chosen as the input language, instead of creating a new
+language from scratch. This has enabled creating the prototype rapidly,
+allowing for experimenting with various functional language features and
+interpretations in Cλash. Even supporting more complex features like
+polymorphism and higher-order values has been possible. If a new language and
+compiler would have been designed from scratch, that new language would not
+have been nearly as advanced as the current version of Cλash.
 
-Haskell is not the perfect language. Some of the expressiveness it offers is
-not appropriate for hardware description, but also some extra syntax sugar
-could be useful. Lack of type-safe recursion is a big downside (but also a
-hard problem!), perhaps improvements to Haskell will fix this.
+However, Haskell might not have been the best choice for describing
+hardware. Some of the expressiveness it offers is not appropriate for
+hardware description (such as infinite recursion or recursive types),
+but also some extra syntax sugar could be useful (to reduce
+boilerplate). 
 
-Explicit state descriptions...
+The lack of real dependent typing support in Haskell has been a burden.
+Haskell provides the tools to create some type level programming
+constructs (and is improving fast), but another language might have
+support for more advanced dependent types (and even type level operations) as
+a fundamental part of the language. The need for dependent typing is
+particularly present in Cλash to be able to fix some properties (list length,
+recursion depth, etc.) at compile time. Having better support for dependent
+typing might allow the use of typesafe recursion in Cλash, though this is
+fundamentally still a hard problem.
 
-Transformation based system is suitable, allows for reasoning about the
-system. Easy to specify transformation in the prototype. Implmentation is stil
-lacking, especially when combined with pattern matching.
+The choice of describing state very explicitly as extra arguments and
+results is a mixed blessing. It provides very explicit specification of
+state, which allows for very clear descriptions. This also allows for
+easy modification of the description in our normalization program, since
+state can be handled just like other arguments and results. 
 
-General design (frontend + desugaring into small language, transformation
-system, simple backend) works well and should be preserved.
+On the other hand, the explicitness of the states and in particular
+substates, mean that more complex descriptions can become cumbersome
+very quickly. One finds that dealing with unpacking, passing, receiving
+and repacking becomes tedious and even errorprone. Removing some of this
+boilerplate would make the language even easier to use.
 
-Usefulness of Cλash is not completely clear yet. Advanced features work
-nicely, as well as choice, but no extensive testing (actual design projects)
-have been done yet. Use in education possible due to prototype.
+On the whole, the usefulness of Cλash for describing hardware is not
+completely clear yet. Most elements of the language have proven
+suitable, and even a real world hardware circuit (the reducer \todo{ref
+christiaan}) has been implemented. However, the language has not been
+used during a complete design process, where its rapid prototyping and
+reusability qualities could become real advantages, or perhaps the state
+boilerplate or synchronicity limitations could become real problems.
 
-Limited to structural, single clock domain synchronous, etc.
+It is expected that Cλash will be used as a tool in education at the
+University of Twente soon. Hopefully this will provide a better insight
+in how the system performs.
+
+The prototype compiler has a clear design. Its frontend is taken from the \GHC\
+compiler and desugars Haskell into a small, but functional and typed
+language, called \emph{Core}. Cλash adds a transformation system that reduces
+this small language to a normal form and a simple backend that performs a
+direct translation to \VHDL. This approach has worked well and should probably
+be preserved. Especially the transformation based normalization system is
+suitable. It is easy to implement a transformation in the prototype, though it
+is not trivial to maintain enough overview to guarantee that the system is
+correct and complete. In fact, the current set of transformations is probably
+not complete yet, in particular when stateful descriptions are involved.
+However, the system can be (and has been) described in a mathematical sense,
+allowing us to reason about it and probably also prove various correctness
+properties in the future.
+
+The scope of this research has been limited to structural descriptions that
+are synchronous in a single clock domain using cycle accurate designs. Even
+though this is a broad spectrum already, it may turn out that this scope is
+too narrow for practical use of Cλash. A common response from people that hear
+about using a functional language for hardware description is that they hope
+to be able to provide a concise mathematical description of their algorithm
+and have the hardware generated for them. Since this is obviously a different
+problem altogether, we could not have hoped to even start solving it. However,
+hopefully the current Cλash system provides a solid base on top of which
+further experimentation with functional descriptions can be built.