blob: 502a5ad1e2ef8a62bbe6b32adc81d61b2c5a8827 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
\section{Conclusion}
\label{sec:concl}
Walking through the implementation of a While interpreter we have seen
different advantages of doing this in a functional style.
First of all, the syntax could be translated directly from grammar to type
definitions. It is true that simple algebraic data types, as used in
\autoref{sec:ast}, could be simulated with enumeration types and pointers in
an imperative style. However, any one will agree that the functional
definitions are better readable, making their usage less error-prone.
Secondly, in \autoref{sec:eval} we saw that functional programming languages
allow us to easily work with higher order functions: we did not need to
implement the state as a lookup table but could simply use a function.
We then discussed the use of the \CI{Either} monad for error reporting. Monadic
binding lets us work easily with calculations that may fail. Moreover, in
\autoref{sec:interp} we saw that monads also let us specify execution order.
In general, we have seen that a functional style allows us to stay close to the
semantic definitions of a language. This makes it very easy to verify that our
implementation of the semantics is correct. Proofs that hold for the semantics
(like completeness or correctness with respect to axiomatic semantics) easily
apply to the interpreter as well, once the correctness of the interpreter has
been established --- this is generally a trivial task. Furthermore, the final
implementation is better readable and thus easier to maintain.
|
