summaryrefslogtreecommitdiff
path: root/paper/paper.tex
diff options
context:
space:
mode:
authorCamil Staps2016-05-09 19:50:13 +0200
committerCamil Staps2016-05-09 19:50:13 +0200
commitaa426ef109371a850a495e5edeb92027ef09e985 (patch)
tree11b69d0bb2ba8370e7f9813203e2dcae045ea7b5 /paper/paper.tex
parentFeedback opdracht 3 (= opdracht 4) (diff)
opdracht 5 & 6
Diffstat (limited to 'paper/paper.tex')
-rw-r--r--paper/paper.tex61
1 files changed, 61 insertions, 0 deletions
diff --git a/paper/paper.tex b/paper/paper.tex
new file mode 100644
index 0000000..5573617
--- /dev/null
+++ b/paper/paper.tex
@@ -0,0 +1,61 @@
+\documentclass[a4paper]{article}
+
+\usepackage[english]{babel}
+\usepackage{geometry}
+\usepackage[hidelinks]{hyperref}
+\usepackage{natbib}
+
+\title{High-level code processing 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).
+
+\bibliographystyle{jfp}
+\bibliography{paper}
+
+\end{document}
+