<commit_before>%%% Local Variables:
%%% mode: latex
%%% TeX-master: "../report"
%%% End:

TODO:Present test methodology as well as results in this section. In addition, if performance
analysis of the system is interesting, present it here as well.
A few screenshots of the program can be included here as well. TODO


\subsection{Preprocessor}
As we use \texttt{cpphs}\cite{wallace04} for preprocessing, which is a
port of the C-preprocessor in Haskell, one will have to take certain
considerations when including files.

One major pitfall is creating circular dependencies. If two files includes
each other, using the \texttt{\#include file.kite} syntax, this will
cause an infinite loop of the files including each-other, resulting in
a stack-overflow. Circular dependencies are not detected which can
cause confusing errors, without any detailed feedback.

Another pitfall is including the same file twice. Take for example the
following set of files and inclusions:

\begin{lstlisting}[caption=\texttt{grandfather.kite}]
  foo = -> { bar }
\end{lstlisting}

\begin{lstlisting}[caption=\texttt{father.kite}]
  #include 'gradfather.kite'
  ...
\end{lstlisting}

\begin{lstlisting}[caption=\texttt{child.kite}]
  #include 'gradfather.kite'
  #include 'father.kite'
  ...
\end{lstlisting}

This will cause a compile-time error, as the \texttt{foo} function is
declared twice, which is not allowed.

Both of these pitfalls can be avoided using include
guards~\footnote{\url{http://en.wikipedia.org/wiki/Include_guard}},
ensuring that a file is only included if a specific flag is not
defined, meaning the file has not yet been included.

\begin{lstlisting}[caption=\texttt{grandfather.kite}]
  #ifndef GRANDFATHER_H
  #define GRANDFATHER_H

  foo = -> { bar }

  #endif
\end{lstlisting}

\begin{lstlisting}[caption=\texttt{father.kite}]
  #include 'gradfather.kite'
  ...
\end{lstlisting}

\begin{lstlisting}[caption=\texttt{child.kite}]
  #include 'gradfather.kite'
  #include 'father.kite'
  ...
\end{lstlisting}


\subsection{Tests}

In the following we will describe the various tests we have performed in order to validate the correctness of the compiler, both throughout the development and of the final system.

We have made use of both \textbf{unit} and \textbf{integration} tests. Unit testing has been used on each of the modules of the compiler. For instance, we have tested the parser module in cases where the output of the lexer should yield a parse error and in cases where it should not.

TODO: More examples of unit testing?

As for integration tests we have written small programs in Kite which we compile and pipe the emitted code into Node.js, and manually check whether the yielded result matches the expected. By doing this we can test whether the entire flow of the compiler is working.

TODO: Is the above lame?

TODO: Make tests of  source -> emit -> run automatic?


\subsection{Optimization}
As our optimization pass removes unused function declarations from the parse tree, it is possible to achieve a substantial reduction of the emitted code.

A very simple program that concatenates the strings `Hello,' and ` World!' and prints them, is unoptimized emitted to 12.5kB of JavaScript, and optimized to 3.5kB. Thus optimization yields a size reduction of 72\%.

A slightly larger program that sums the even Fibonacci numbers less than 4 million (problem 2 of the online collection of mathematical problems Project Euler\cite{euler}) the compiler emits 12.9kB and 6.8kB of JavaScript without and with optimization, respectively. The program makes use of list comprehensions, which is just syntactic sugar for flatten and map, which then again uses a cascade of functions from Foundation.kite. Thus it is expected that a lot of the code from the library is used. But a reduction of 47\% is still noteworthy, and imagining the use of functions from other Kite-libraries for more specific purposes, this optimization might be useful.

\begin{center}
  \begin{tabulary}{0.9\textwidth}{|L| L |L| C | L | }
    \hline
    Program & Size without optimization & Size with optimization & Percent reduction & Comment \\
    \hline
    Hello.kite       & 12.5 kB & 3.5 kB & 72 \% & A program that concatenates two strings prints the result \\
    & & & & \\
    Euler1 .kite       & 12.7 kB & 6.6 kB & 48 \% & A program that sums all numbers smaller than 1000 divisible by 3 or 5 \\<commit_msg>Added some testing in evaluation<commit_after>%%% Local Variables:
%%% mode: latex
%%% TeX-master: "../report"
%%% End:

TODO:Present test methodology as well as results in this section. In addition, if performance
analysis of the system is interesting, present it here as well.
A few screenshots of the program can be included here as well. TODO

TODO: kite.mode for emacs


\subsection{Preprocessor}
As we use \code{cpphs}\cite{wallace04} for preprocessing, which is a
port of the C-preprocessor in Haskell, one will have to take certain
considerations when including files.

One major pitfall is creating circular dependencies. If two files includes
each other, using the \code{\#include file.kite} syntax, this will
cause an infinite loop of the files including each-other, resulting in
a stack-overflow. Circular dependencies are not detected which can
cause confusing errors, without any detailed feedback.

Another pitfall is including the same file twice. Take for example the
following set of files and inclusions:

\begin{lstlisting}[caption=\code{grandfather.kite}]
  foo = -> { bar }
\end{lstlisting}

\begin{lstlisting}[caption=\code{father.kite}]
  #include 'gradfather.kite'
  ...
\end{lstlisting}

\begin{lstlisting}[caption=\code{child.kite}]
  #include 'gradfather.kite'
  #include 'father.kite'
  ...
\end{lstlisting}

This will cause a compile-time error, as the \code{foo} function is
declared twice, which is not allowed.

Both of these pitfalls can be avoided using include
guards~\footnote{\url{http://en.wikipedia.org/wiki/Include_guard}},
ensuring that a file is only included if a specific flag is not
defined, meaning the file has not yet been included.

\begin{lstlisting}[caption=\code{grandfather.kite}]
  #ifndef GRANDFATHER_H
  #define GRANDFATHER_H

  foo = -> { bar }

  #endif
\end{lstlisting}

\begin{lstlisting}[caption=\code{father.kite}]
  #include 'gradfather.kite'
  ...
\end{lstlisting}

\begin{lstlisting}[caption=\code{child.kite}]
  #include 'gradfather.kite'
  #include 'father.kite'
  ...
\end{lstlisting}


\subsection{Tests}
In the following section we will describe the various tests we have
implemented in order to validate the correctness of the compiler, both
throughout the development and of the final system.

We have made use of both \textbf{unit}- and \textbf{integration}
tests. Unit-testing for ensuring that each component, e.i. module, of the compiler,
e.g. the lexer, parser etc., are \emph{indidually} functioning as
expected. Where as, the integration-tests have been focused on that
the interface between the various components are functioning as
expected.

\subsubsection{Unit-testing}
Unit testing has been used on each of the modules of the
compiler. For instance, we have tested the parser module in cases
where the output of the lexer should yield a parse error and in cases
where it should not.

\begin{lstlisting}[caption=\code{Kite.Test.TypeCheck.hs} snippet]
  ...
      , testE "List assignment same type"
      Nothing "list = [1, 2, 3]"

    , testE "List assignment illegal values"
      (Just TypeE) "list = [1, True, \"Three\"]"
  ...
\end{lstlisting}

Above we have two test cases of the type checker module. In the first
we check that a legal list assignment should \emph{not} yield an
error, while the second, where a list is declared with distinct types,
should yield a type error of type \code{TypeE}.

\subsubsection{Integration-tests}
As for integration-tests, we have written small programs in Kite which
we compile and pipe the emitted code into Node.js, and manually check
whether it yields the expected result. By doing this we can test
whether the entire flow of the compiler is working as expected.

This can be run command-line with: \code{\$ kite --target=javascript examples/Test.kite | node}

\subsubsection{Continuous integration}
Through out the development of the Kite-compiler we have used
continuous integration (CI) to incrementally check that new changed as
not broken anything in the compiler. We have done this by triggering a
make of the code-base, when changes are pushed to the master branch of
the source-code repository. For this we have used a free service
called Travis~\fottnote{\url{https://travis-ci.org/}}.

The advantages of using CI is that any changes that breaks the build
will immediately be detected, and that the party to blame will be
notified so he/she can fix it before it disrupts further development.


\subsection{Optimization}
As our optimization pass removes unused function declarations from the parse tree, it is possible to achieve a substantial reduction of the emitted code.

A very simple program that concatenates the strings `Hello,' and ` World!' and prints them, is unoptimized emitted to 12.5kB of JavaScript, and optimized to 3.5kB. Thus optimization yields a size reduction of 72\%.

A slightly larger program that sums the even Fibonacci numbers less than 4 million (problem 2 of the online collection of mathematical problems Project Euler\cite{euler}) the compiler emits 12.9kB and 6.8kB of JavaScript without and with optimization, respectively. The program makes use of list comprehensions, which is just syntactic sugar for flatten and map, which then again uses a cascade of functions from Foundation.kite. Thus it is expected that a lot of the code from the library is used. But a reduction of 47\% is still noteworthy, and imagining the use of functions from other Kite-libraries for more specific purposes, this optimization might be useful.

\begin{center}
  \begin{tabulary}{0.9\textwidth}{|L| L |L| C | L | }
    \hline
    Program & Size without optimization & Size with optimization & Percent reduction & Comment \\
    \hline
    Hello.kite       & 12.5 kB & 3.5 kB & 72 \% & A program that concatenates two strings prints the result \\
    & & & & \\
    Euler1 .kite       & 12.7 kB & 6.6 kB & 48 \% & A program that sums all numbers smaller than 1000 divisible by 3 or 5 \\
{'fraction_non_alphanumeric': 0.07614998067259374, 'fraction_numerical': 0.00831078469269424, 'mean_word_length': 4.1745, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 9, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2330289', 'n_tokens_mistral': 2943, 'n_tokens_neox': 2755, 'n_words': 1375}