From: Matthijs Kooijman <matthijs@stdin.nl>
Date: Thu, 3 Dec 2009 16:43:16 +0000 (+0100)
Subject: Add a section on normalization of stateful descriptions.
X-Git-Tag: final-thesis~112
X-Git-Url: https://git.stderr.nl/gitweb?a=commitdiff_plain;h=d081fa803ef206c6f7ffa72941ca7f008915c69f;p=matthijs%2Fmaster-project%2Freport.git

Add a section on normalization of stateful descriptions.
---

diff --git a/Chapters/Normalization.tex b/Chapters/Normalization.tex
index f9a1015..37895b3 100644
--- a/Chapters/Normalization.tex
+++ b/Chapters/Normalization.tex
@@ -2060,6 +2060,37 @@
         transformations will probably need updating to handle them in all
         cases.
 
+      \subsection{Normalization of stateful descriptions}
+        Currently, the intended normal form definition\refdef{intended
+        normal form definition} offers enough freedom to describe all
+        valid stateful descriptions, but is not limiting enough. It is
+        possible to write descriptions which are in intended normal
+        form, but cannot be translated into \VHDL in a meaningful way
+        (\eg, a function that swaps two substates in its result, or a
+        function that changes a substate itself instead of passing it to
+        a subfunction).
+
+        It is now up to the programmer to not do anything funny with
+        these state values, whereas the normalization just tries not to
+        mess up the flow of state values. In practice, there are
+        situations where a Core program that \emph{could} be a valid
+        stateful description is not translateable by the prototype. This
+        most often happens when statefulness is mixed with pattern
+        matching, causing a state input to be unpacked multiple times or
+        be unpacked and repacked only in some of the code paths.
+
+        \todo{example?}
+
+        Without going into detail about the exact problems (of which
+        there are probably more than have shown up so far), it seems
+        unlikely that these problems can be solved entirely by just
+        improving the \VHDL state generation in the final stage. The
+        normalization stage seems the best place to apply the rewriting
+        needed to support more complex stateful descriptions. This does
+        of course mean that the intended normal form definition must be
+        extended as well to be more specific about how state handling
+        should look like in normal form.
+
   \section[sec:normalization:properties]{Provable properties}
     When looking at the system of transformations outlined above, there are a
     number of questions that we can ask ourselves. The main question is of course: