%---------------------------------------------------------------------------------------------------------------------%
%----- Evaluator
%---------------------------------------------------------------------------------------------------------------------%
\chapter{Evaluator}

This section describes the fundamental evaluation-mechanism for \LOMFii functions.
The following figure \ref{fig:evatypeHierarchy} shows the customized model-structure.
To keep the additional components seperate from the original \type{Model}, an abstract
class \type{AbstractModel} has been extracted. A model that is defined in the
model tab of the application is parsed to a \type{Model} object and called
\term{typeModel}. A model defined in the test tab of the application is parsed
to a \type{EvaluableModel} object and uses the typeModel to evaluate its
expressions. 

\begin{figure}[h!]
  \centering
    \includegraphics[width=\textwidth]{pictures/evaluation_model.pdf}
  \caption{Evaluable Modell}
  \label{fig:evatypeHierarchy}
\end{figure}

All abstract operations in \type{EvaluableModel} will be implemented by delegation-pattern 
using the concrete model (association \code{typeModel} see figure \ref{fig:evatypeHierarchy}).

The \type{EvaluableModel} was extended by the following list of evaluable
functions:
\begin{codeblock}
+evaluableFunctions: Collection<FunctionExpression>
\end{codeblock}
 
Additionally a model is required that contains all evaluated values.
The following figure (\ref{fig:evaDataModel}) shows the defined model.

\begin{figure}[h!]
  \centering
    \includegraphics[width=\textwidth]{pictures/evaluation_data_model.pdf}
  \caption{Evaluation Datamodel}
  \label{fig:evaDataModel}
\end{figure}

The association \code{Elements} represents the possible projections of an
evaluated expression.\footnote{E. g. the type \code{Succ(Null)} contains one element of
type \type{TypedData} (Null). A sum contains an element for each summand.}

The class \type{Data} provides an abstraction for the following, four concrete
\q{value-types}:


\begin{description}
\item[TypeData]
Provides a typed and evaluated value (e. g. \code{Null}).\footnote{Note: At
least one concrete type has to be assigned.}

\item[ApplyableFunction] Represents a not yet executed function, which is the result of an\\
\type{AnonymousFunctionExpression} in the evaluation.
\item[ConstantTypeData] This type represents an evaluated constant value, which
is typed in a \type{BuiltInType}.
\item[DerivedTypeData] Provides an evaluated sum or product, in which the concrete type is not determined explicitly\footnote{Like the name  \type{DerivedTypeData} suggest.}.
\end{description}


\section{Evaluation Algorithms}

\begin{figure}[h!]
  \centering
    \includegraphics[width=\textwidth]{pictures/evaluators.pdf}
  \caption{Evaluation-Strategies}
  \label{fig:evaluatoren}
\end{figure}

The interface \type{Evaluator} was created for the evaluation and provides the necessary operations.
Entrypoint for evaluation is the following operation: 
\begin{codeblock}
+evaluate(FunctionExpression): Data
\end{codeblock}

There are two concrete evaluators: 
\type{StackEvaluator}\footnote{This evaluator was created to gain the ability of developing an \LOMFii -internal debugger.} 
and \type{RecursiveEvaluator}. \LOMFii uses the \type{RecursiveEvaluator} which
evaluates a \type{FunctionExpression} recursively,
while the \type{StackEvaluator} does this by using a stack.

The basic evaluation of expressions will be described in the following
overview (see table \ref{tbl:evaluation} below). The general evaluation works as follows:

\begin{center}
\code{\textcolor{red}{V} A $\rightsquigarrow$ \textcolor{red}{A(V)}}
\end{center}

The $\rightsquigarrow$ suggest a replacement process. The expression on the left side of an arrow, will replaced by the right side. For example in case of a product, the description in table \ref{tbl:evaluation} means, that the expression \textcolor{red}{V} will applied on every element of the product.

Most of the following cases require, that the evaluation remember at least parts of the \textcolor{red}{V} to use them for further evaluations. To accomplish that requirement, the evaluation works as a stack (or, as described before, recursively).

% Zeilen in der Evaluationtabelle
\newcommand{\evalHeadline}{	\thl{Semantics}		&	\thl{Syntax}}
\newcommand{\evalLineNoCode}[3][]{\tr[]		\code{#2}	&
#3}
\newcommand{\evalLine}[3][]{\evalLineNoCode[#1]{#2}{\code{#3}}}

\tblNoBorder{Evaluation}{evaluation}{ll}{%
	\evalHeadline
	\evalLine{Projection}{\textcolor{red}{V}.i $\rightsquigarrow$
	\textcolor{red}{V(i)}}
	\evalLine{Operation}{\textcolor{red}{V} op $\rightsquigarrow$
	\textcolor{red}{V} $method^{Op}(v)$}
	\evalLine{Identity}{\textcolor{red}{V}. $\rightsquigarrow$ \textcolor{red}{V}}
	\evalLine{Terminal}{\textcolor{red}{V}! $\rightsquigarrow$ \textcolor{red}{()}}
	\evalLine{Sum}{\textcolor{red}{V} \{$s_1, \dots ,s_n$\} $\rightsquigarrow$
	\textcolor{red}{V} \{$s_1, \dots ,s_n$\}(v)} \evalLine{Product}{\textcolor{red}{V} ($f1, \dots ,f_n$) $\rightsquigarrow$
	(\textcolor{red}{V} $f1, \dots , \textcolor{red}{V}f_n$)} \evalLine{Constant}{\textcolor{red}{V} constant $\rightsquigarrow$
	\textcolor{red}{$V_{constant}$}}
}{\defaultTblBg}\label{tbl:evaluation}