X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FNormalization.tex;h=907411e877ef6bb9d2d1a30c67fd5d94774527a5;hp=cf905c3c6155003bef0419d251ebafaef4cd1e36;hb=b92b16b7e4ab854699bcd151bad0be7c5d73c0ae;hpb=a5c24fad8b59d741bc4bafd73405bb54b5c3934e

diff --git a/Chapters/Normalization.tex b/Chapters/Normalization.tex
index cf905c3..907411e 100644
--- a/Chapters/Normalization.tex
+++ b/Chapters/Normalization.tex
@@ -2060,7 +2060,7 @@
         transformations will probably need updating to handle them in all
         cases.
 
-      \subsection{Normalization of stateful descriptions}
+      \subsection[sec:normalization:stateproblems]{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
@@ -2079,8 +2079,6 @@
         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
@@ -2090,6 +2088,9 @@
         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.
+        \in{Section}[sec:prototype:statelimits] already contains a
+        tight description of the limitations on the use of state
+        variables, which could be adapted into the intended normal form.
 
   \section[sec:normalization:properties]{Provable properties}
     When looking at the system of transformations outlined above, there are a