diff options
author | Camil Staps | 2016-05-18 23:26:56 +0200 |
---|---|---|
committer | Camil Staps | 2016-05-18 23:26:56 +0200 |
commit | f7047c8e28285e5ff3887ed5fcc889183e28f959 (patch) | |
tree | a21f704cca774b39e74621cf9dd4d271bb9d5cbc /paper | |
parent | Opdracht 8 (diff) |
Start rewrite intro; add organisation; division in separate files
Diffstat (limited to 'paper')
-rw-r--r-- | paper/abs.tex | 10 | ||||
-rw-r--r-- | paper/intro-org.tex | 11 | ||||
-rw-r--r-- | paper/intro-while.tex | 3 | ||||
-rw-r--r-- | paper/intro.tex | 30 | ||||
-rw-r--r-- | paper/paper.tex | 45 |
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} |