Update conclusions.

diff --git a/Chapters/Conclusions.tex b/Chapters/Conclusions.tex
index c12e99d0665c6d3f172573f86993804c5670bca3..111d69ce424e3ba12449a6cc36f70f25fdfc5ae1 100644 (file)
--- a/Chapters/Conclusions.tex
+++ b/Chapters/Conclusions.tex
@@ -10,29 +10,78 @@ case expressions, if expressions) are well suited to describe conditional
 assigment in the hardware.
 
 Useful features from the functional perspective, like polymorphism and higher
 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.
+order functions and expressions also prove suited 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.
+Using Haskell as as source language in this research has proven
+fruitful. It has enabled creating a prototype rapidly, to experiment
+with various language features 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
+language would not have been nearly as advanced as current 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 other 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 explictness of the states and in particular
+substates, mean that more complex descriptions can become cumbersome
+very quick.  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 haven 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 general design of the prototype (A frontend that desugares into a
+small, but functional and typed language, a transformation
+system that works on this small language, and a simple backend) has
+worked well and should probably be preserved. Especially the
+transformation based normalization system is suitable. It is easy to
+program 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. Most people
+that hear about using a functional language for hardware description
+instantly 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 alltogether, 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.