up
[phd-thesis.git] / top / imp.tex
index 1efd361..5264796 100644 (file)
@@ -204,7 +204,7 @@ instance expr BCInterpret where
                e >>| tell` [BCLabel endiflabel]
 \end{lstClean}
 
-\subsection{Functions}
+\subsection{Functions}\label{ssec:functions}
 Compiling functions occurs in $\mathcal{F}$, which generates bytecode for the complete program by iterating over the functions and ending with the main expression.
 When compiling the body of the function, the arguments of the function are added to the context so that the addresses can be determined when referencing arguments.
 The main expression is a special case of $\mathcal{F}$ since it neither has arguments nor something to continue.
@@ -293,7 +293,7 @@ callFunction :: JumpLabel UInt8 [BCInterpret b] -> BCInterpret c | ...
 liftFunction :: JumpLabel UInt8 (BCInterpret a) (?UInt8) -> BCInterpret ()
 \end{lstClean}
 
-\subsection{Tasks}
+\subsection{Tasks}\label{ssec:scheme_tasks}
 Task trees are created with the \cleaninline{BCMkTask} instruction that allocates a node and pushes it to the stack.
 It pops arguments from the stack according to the given task type.
 The following extension of $\mathcal{E}$ shows this compilation scheme (except for the step combinator, explained in \cref{ssec:step}).
@@ -529,5 +529,8 @@ If a task is to be removed, tasks with higher memory addresses are moved down.
 For task trees---stored in the heap---the \gls{RTS} already marks tasks and task trees as trash during rewriting so the heap can be compacted in a single pass.
 This is possible because there is no sharing or cycles in task trees and nodes contain pointers pointers to their parent.
 
+\section{Conclusion}
+\todo[inline]{conclusion}
+
 \input{subfilepostamble}
 \end{document}