summaryrefslogtreecommitdiff
path: root/paper
diff options
context:
space:
mode:
authorCamil Staps2016-05-18 23:26:56 +0200
committerCamil Staps2016-05-18 23:26:56 +0200
commitf7047c8e28285e5ff3887ed5fcc889183e28f959 (patch)
treea21f704cca774b39e74621cf9dd4d271bb9d5cbc /paper
parentOpdracht 8 (diff)
Start rewrite intro; add organisation; division in separate files
Diffstat (limited to 'paper')
-rw-r--r--paper/abs.tex10
-rw-r--r--paper/intro-org.tex11
-rw-r--r--paper/intro-while.tex3
-rw-r--r--paper/intro.tex30
-rw-r--r--paper/paper.tex45
5 files changed, 57 insertions, 42 deletions
diff --git a/paper/abs.tex b/paper/abs.tex
new file mode 100644
index 0000000..f7170c8
--- /dev/null
+++ b/paper/abs.tex
@@ -0,0 +1,10 @@
+\begin{abstract}
+ As the tools provided by programming languages become more abstract and
+ semantically complex, it becomes necessary to have systems that can reason
+ about these programming languages on a high abstraction level. Functional
+ languages can aid interpreter and compiler designers: abstraction is trivial,
+ and the close link with mathematics makes it easy to prove properties about
+ programs. By means of a case study, an interpreter of the language
+ While~\citep{proganal}, the advantages of a functional language for
+ imperative code interpretation are shown.
+\end{abstract}
diff --git a/paper/intro-org.tex b/paper/intro-org.tex
new file mode 100644
index 0000000..55231b7
--- /dev/null
+++ b/paper/intro-org.tex
@@ -0,0 +1,11 @@
+\subsection{Paper organistation}
+\label{sec:intro:org}
+In this paper we present different advantages of working with imperative code
+in a functional style. We do this by means of a case study, an interpreter of
+the language While~\citep{proganal}. After describing While briefly in
+\autoref{sec:intro:while}, we will iteratively build our interpreter: the lexer
+in \autoref{sec:lexer}, the parser in \autoref{sec:parser} and the actual
+interpreter in \autoref{sec:interpreter}. As an intermezzo, in
+\autoref{sec:evaluation} we discuss different possibilities of evaluating
+mathematical expressions. Finally, in \autoref{sec:conclusions} we precisely
+articulate the advantages of functional interpretation.
diff --git a/paper/intro-while.tex b/paper/intro-while.tex
new file mode 100644
index 0000000..5824d0e
--- /dev/null
+++ b/paper/intro-while.tex
@@ -0,0 +1,3 @@
+\subsection{The language While}
+\label{sec:intro:while}
+%todo
diff --git a/paper/intro.tex b/paper/intro.tex
new file mode 100644
index 0000000..49fbeed
--- /dev/null
+++ b/paper/intro.tex
@@ -0,0 +1,30 @@
+\section{Introduction}
+\label{sec:intro}
+Compilers and interpreters are among the most complex pieces of software
+written to date. Due to the rapid technological development of the last
+decades, programming languages have become increasingly complex, semantically
+speaking. It has become impossible for a programmer to keep in mind the impact
+of their changes on the generated machine code. This led to the
+\emph{assumption problem}: developers constantly rely on assumptions about how
+the language that they write in works. Intuitive semantics may change over
+time, however, and proper definitions are required now that our world relies so
+principally on software.
+
+Nowadays, programming languages have semantical specifications as the main link
+between programmers and compiler designers. This solves the assumption problem
+on the programmer's side. However, now that programming languages become
+increasingly complex, the same problem occurs on the compiler designer's side:
+the specification has become too complex to efficiently translate it into
+imperative code, and writing a correct compiler or interpreter has become no
+trivial task.
+
+Functional programming languages offer writers of code processing systems tools
+to efficiently work with semantical specifications. Using a high level of
+abstraction, the gap between specification and implementation is closed,
+allowing for quicker correctness checks and better maintainable code. The
+connections between functional languages and mathematics let us \emph{prove}
+properties about code processing systems (for example, their correctness with
+respect to a specification).
+
+\input{intro-org}
+\input{intro-while}
diff --git a/paper/paper.tex b/paper/paper.tex
index 5573617..1cb89cd 100644
--- a/paper/paper.tex
+++ b/paper/paper.tex
@@ -5,54 +5,15 @@
\usepackage[hidelinks]{hyperref}
\usepackage{natbib}
-\title{High-level code processing in a functional style}
+\title{Imperative code interpretation in a functional style}
\author{Camil Staps}
\begin{document}
\maketitle
-\begin{abstract}
- As the tools provided by programming languages become more abstract and
- semantically complex, it becomes necessary to have systems that can reason
- about these programming languages on a high abstraction level. Functional
- languages can aid interpreter and compiler designers: abstraction is trivial,
- and in addition to that the use of a functional language makes it easier to
- prove properties about programs. By means of a case study, an interpreter of
- the language While \citep{proganal}, the advantages of functional languages
- for code processing are shown.
-\end{abstract}
-
-\section{Introduction}
-Compilers and interpreters are among the most complex pieces of software
-written to date. Due to the rapid technological development of the last
-decades, programming languages have become semantically so complex, that it is
-impossible for a programmer to keep in mind the impact of changes on generated
-machine code. This led to the \emph{assumption problem}: developers constantly
-rely on assumptions about how the language that they write in works. Intuitive
-semantics may change over time, however, and we cannot found a world relying so
-principally on software as ours on contingent assumptions.
-
-Algol 60 was the first language of which the semantics were precisely
-documented \citep{algol}. Its report is the primary link between Algol
-programmers and the compiler designers, clarifying the language for the first
-and specifying it for the second. These kind of specifications were the first
-solution to the assumption problem.
-
-However, programming languages have evolved significantly since Algol 60, and
-semantical specifications have become increasingly complex. Whereas the
-assumption problem has been solved on the programmer's side, it has now
-occurred on the compiler designer's side: the specification has become too
-mathematically complex to efficiently translate it into imperative code, and
-writing a correct compiler or interpreter is no longer trivial.
-
-Functional programming languages offer writers of code processing systems tools
-to efficiently implement semantical specifications. Using a higher level of
-abstraction, the gap between specification and implementation is closed,
-allowing for quicker correctness checks and better maintainable code. The
-connections between functional languages and mathematics let us \emph{prove}
-properties about code processing systems (for example, their correctness with
-respect to a specification).
+\input{abs}
+\input{intro}
\bibliographystyle{jfp}
\bibliography{paper}