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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
% vim: set spelllang=nl:
\subsection{Types}
\label{sec:cleansmurf:types}
Het programma houdt de expressieve syntax uit \autoref{sec:def:syn} aan. Dit
geeft de types:
\lstinputlisting[firstline=15,lastline=20]{CleanSmurf/Smurf.dcl}
We modelleren lijsten als stacks en implementeren de store met behulp van een
tabel van naam-waarde paren:
\lstinputlisting[firstline=22,lastline=27]{CleanSmurf/Smurf.dcl}
Ten slotte definiëren we transities. Aangezien alle semantiekregels hooguit één
premisse hebben, kunnen we een afleidingsboom als lijstje transities zien:
\lstinputlisting[firstline=35,lastline=36]{CleanSmurf/Smurf.dcl}
Met deze definities zouden we een \CI{step :: Program State -> Maybe (Program,
State)} kunnen definiëren. Dit type komt bijna overeen met de structuur van
transities. We moeten echter een \CI{Program} teruggeven, omdat we slechts één
stap zetten. Wat dit betreft lijken de regels van \emph{CleanSmurf} meer op
regels in structurele operationele semantiek. We hebben al laten zien dat deze
regels niet wezenlijk afwijken van die voor de natuurlijke semantiek.
In het type van \CI{step} zit nog geen Input/Output. We maken er een overloaded
functie van, zodat hij voor meerdere inputmethodes kan worden gebruikt. Het
uiteindelijke type is dan:
\lstinputlisting[firstline=56,lastline=56]{CleanSmurf/Smurf.dcl}
Het derde argument, van type \CI{io}, is de `IO-toestand'. Het vierde argument,
van type \CI{IO io}, omvat een input-functie die strings oplevert (gegeven de
IO-toestand) en een output-functie die strings opneemt (in de IO-toestand). Hoe
dit precies werkt is niet belangrijk voor de beschrijving hier.
\medskip
Verder definiëren we een aantal hulpfuncties op onze types:
\lstinputlisting[firstline=232,lastline=245]{CleanSmurf/Smurf.icl}
De partiële functies zijn hier gesimuleerd met het \CI{Maybe}-type. Dit laat
ons monadische operatoren gebruiken in het uitwerken van de interpreter. Wilden
we betekenisvolle error messages geven zoals de Perl-interpreter doet, dan
hadden we \CI{Either} kunnen gebruiken. Dit maakt geen verschil voor de
implementatie van de semantiekregels.
|
