From 14ec0ad883bc51fb16c72472e060ff0443e29533 Mon Sep 17 00:00:00 2001
From: Camil Staps
Date: Fri, 3 Jun 2016 13:31:46 +0200
Subject: Finishing first version paper

---
 paper/intro.tex | 31 ++++++++++++++++++-------------
 1 file changed, 18 insertions(+), 13 deletions(-)

(limited to 'paper/intro.tex')

diff --git a/paper/intro.tex b/paper/intro.tex
index 49fbeed..2d44b4a 100644
--- a/paper/intro.tex
+++ b/paper/intro.tex
@@ -4,27 +4,32 @@ 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
+of their changes on the generated machine code. Developers now 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
+between programmers and compiler designers. This solves the problem on the
+programmer's side. However, now that programming languages become increasingly
+complex, another 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 is no longer a
 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).
+to efficiently work with semantical specifications --- indeed, functional
+programs can be used as the very specification themselves~\citep{fpasspec}.
+However, we will not go this far. While functional programs are indeed better
+suitable for semantic specifications than natural language, mathematical
+notation gives even more freedom. We therefore suggest tools for the
+implementation of these mathematical definitions in a functional style.
+
+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}
-- 
cgit v1.2.3

