summaryrefslogtreecommitdiff
path: root/paper/intro.tex
diff options
context:
space:
mode:
authorCamil Staps2016-06-03 13:31:46 +0200
committerCamil Staps2016-06-03 13:31:46 +0200
commit14ec0ad883bc51fb16c72472e060ff0443e29533 (patch)
treeac2174232e9546987b988f34a5a2ef6140998093 /paper/intro.tex
parentRewrite eval for AExpr (diff)
Finishing first version paper
Diffstat (limited to 'paper/intro.tex')
-rw-r--r--paper/intro.tex31
1 files changed, 18 insertions, 13 deletions
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}