deliverables/report/intro.tex

   1 \section{Introduction}
   2 \subsection{\SPLC}
   3 \SPLC{} is a compiler written in the purely functional lazy programming language
   4 Clean\footnote{\url{http://clean.cs.ru.nl/Clean}}. \SPLC{} has a standardized
   5 UNIX like command line interface and functions as a filter in a way that it
   6 processes standard input to standard output. Default command line argument such
   7 as \texttt{--version} and \texttt{--help} provide the expected output. To
   8 illustrate all the command line interface options the output of \texttt{spl
   9 --help} is given in Listing~\ref{lst:splchelp}.
  10
  11 \begin{lstlisting}[
  12         label={lst:splchelp},
  13         caption={Output of \texttt{./spl -h}}]
  14 Usage: spl [OPTION] [FILE]
  15
  16 Options:
  17   --help             Show this help
  18   --version          Show the version
  19   --[no-]lex         Lexer output(default: disabled)
  20   --[no-]parse       Parser output(default: disabled)
  21   --[no-]sem         Semantic analysis output(default: disabled)
  22   --[no-]code        Code generation output(default: enabled)
  23 \end{lstlisting}
  24
  25 \subsection{Outline}
  26 \SPLC{} has several phases that each produce their own output. Via command
  27 line flags the user can enable or disable the printing of the output of
  28 specific phases. The output for the code generation is enabled by default and
  29 the output for the other phases are disabled by default.
  30
  31 The first and second steps are lexing and parsing, which are both explained in
  32 Section~\ref{sec:pars}. When one enables only the parsing the program will show
  33 the pretty printed parsed source which is valid \SPL{} code. A simple selftest
  34 can thus be done by feeding the pretty printed output back into \SPLC{}. This
  35 is show in Listing~\ref{lst:splcex}.
  36
  37 The third phase is the semantic analysis phase. In this phase the types are
  38 inferred where necessary and they are checked. There are also some trivial
  39 sanity checks executed to make sure the program is a valid one. When one
  40 enables the printing of the third phase you are shown the pretty printed source
  41 code with all types inferred and the internal dictionary used for typechecking.
  42 This phase is elaborated upon in Section~\ref{sec:sem}.
  43
  44 The last and fourth phase is the code generation phase. \SPLC{} generates
  45 \SSM\footnote{\url{http://www.staff.science.uu.nl/~dijks106/SSM/}}
  46 assembly. \SSM{} assembly is a educational assembly language designed for
  47 compiler construction courses and provides the programmer with handy tools such
  48 as an emulator, breakpoints and a couple of higher level assembly instructions.
  49 Details on code generation is explained in Section~\ref{sec:gen}. Since \SPLC{}
  50 acts as a filter and the \SSM{} emulator does too one can chain the commands
  51 together with standard pipes as shown in Listing~\ref{lst:splcex}.
  52
  53 \begin{lstlisting}[
  54         label={lst:splcex},
  55         caption={Example \SPLC{} run},
  56         language=sh]
  57 # Run a program
  58 spl input.spl | java -jar ssm.jar --stdin --cli
  59 # Selftest parser
  60 diff -q \
  61         <(spl --parse --no-code input.spl) \
  62         <(spl --parse --no-code input.spl | spl --parse --no-code)
  63 \end{lstlisting}
  64
  65 \subsection{Extensions}
  66 Several bigger and smaller extensions to the specification have been made for
  67 the sake of the assignment but also to make programming in \SPL{} more easy.
  68 The big extension for the assignment is the addition of higher order functions.
  69 We have chosen to not implement them in the way of popular functional languages
  70 such as \emph{Clean} and \emph{Haskell} with full closure but to implement them
  71 with \emph{C}-style function pointers. Besides function pointers it is also
  72 possible to already curry some arguments in the function. Details of this are
  73 shown in the higher order function part of Section~\ref{sec:gen}.
  74
  75 Several syntactic sugars have also been added to make programming more easy.
  76 The sugars added are literal lists, literal strings, let expressions, lambda
  77 functions and variable argument printing. All sugars are implemented in the
  78 parsing or lexing phase and thus shown in Section~\ref{sec:pars} except for
  79 lambda expressions which are shown in Section~\ref{sec:sem}.