\section{Extensions}
\subsection{Higher order functions}
+The nature of the type checking algorithm already included type checking and
+inferring the type of higher order functions. Since we allow constants there is
+a difference between \SI{read} and \SI{read()}. To make this difference we
+introduced a separate type of expression called a \SI{FuncType}, this type
+encodes a function with arity $0$.
+
+As all other data types a function type object occupies one item on the stack
+which contains a heap pointer. The heap pointer points to a position on the
+heap that stores, in increasing addresses, the function identification number,
+the number of arguments already given and finally the argument values.
+For example the following snippet shows the representation of the incomplete
+function \SI{plus} that already has two arguments.
+\begin{SPLCode}
+//SPLCode
+plus(x, y, z){ return x + y + z; }
+
+main(){
+ var a = plus(4, 3);
+}
+
+/*# | Stack
+001 | 001 //Pointer to the
+... |
+
+ # | Heap
+001 | 008 //Function identification number
+002 | 002 //Available arguments
+003 | 004 //Argument 1
+004 | 003 //Argument 2
+*/
+\end{SPLCode}
+
+When an incomplete function is declared we save the remaining arity in our
+state to be able to know when a function is complete and can be executed. When
+a function is still not complete the function is copied in totality and the
+available arguments position on the heap is increased accordingly and the
+arguments are added on the heap.
+
+Function numbers are integers that identify the function. Normally we address
+functions using labels but it is not possible to store labels on the heap or on
+the stack. Therefore we include a function in the preamble that is basically a
+dictionary from integers to labels. All functions have their unique number that
+identifies them via the function dictionary called \SI{1func}. When we want to
+call a function that is identified by an address instead of a label we first
+collect all the arguments from the heap and add the arguments given in the
+function call. Calculating the number of arguments that have to be popped from
+the heap is done at runtime using the \emph{Available Arguments} value stored
+on the heap. Instead of jumping to a label we jump to the \SI{1func} function
+and make sure the identification is situated in register R5. \SI{1func} then
+makes sure the correct function is branched to and the caller can resume the
+normal execution path.
+
\subsection{Syntactic sugars}
Several small syntactic sugars have been added on several levels of processing
\end{SPLCode}
\subsubsection{Anonymous functions}
-%TODO
+When the programmers wants to use small functions that consist of one line to
+for example use the operators in a functional way the programmer has to make a
+named function for every operator. In some cases it is easy to do this inline
+using anonymous functions. A small syntactic sugar has been added that will
+inline anonymous functions to non-anonymous functions during the parsing phase.
+The following snippet is an example of a filter on even values before and after
+transformation.
+
+\begin{SPLCode}
+//Before transformation
+main(){
+ var a = filter(\x->x % 2 == 0, 1 : 2 : 3 : 4 : 5 : []);
+}
+
+//After transformation
+1lambda_23(x){
+ return x % 2 == 0;
+}
+
+main(){
+ var a = filter(1lambda_23, 1 : 2 : 3 : 4 : 5 : []);
+}
+\end{SPLCode}
+
+Every anonymous functions gets a unique name outside the namespace of legal
+names for functions making sure the name is unique. By implementing the
+transformation in the parsing phase the function is automatically checked
+or inferred on type.
\subsubsection{Variable arguments printing}
To ease the programmer we have included a parse-level transformation that
repositories / cc1516.git / commitdiff