You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: kiselyov.md
+87-1Lines changed: 87 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,7 +37,7 @@ My implementation closely follows Ben Lynn's implementation of Kiselyov's algori
37
37
My parser can parse programs of a very rudimentary language that is basically just pure λ-calculus plus integers. Here is an example:
38
38
39
39
```haskell
40
-
sqr =\x ->* x x
40
+
sqr =λx.* x x
41
41
main = sqr 3
42
42
```
43
43
@@ -64,6 +64,90 @@ type Environment = [(String, Expr)]
64
64
65
65
Now we can define a compiler that translates such λ-expressions to combinator terms.
66
66
67
+
Our journey begins by translating λ-expressions to a datatype `DB` which is quite similar to the λ-calculus terms but uses indices instead of variable names.This is done by the function `deBruijn`:
It's easy to see that the de Bruijn notation is just a different representation of the λ-calculus terms. The only difference is that the variable names are replaced by indices.
112
+
This is quite helpful as it allows to systematically adress variables by their respective position without having to deal with arbitrary variable names.
113
+
114
+
But why are we using Peano numbers for the indices? Why not just use integers?
115
+
Well it's definitely possible to [use integers instead of Peano numbers](https://crypto.stanford.edu/~blynn/lambda/cl.html).
116
+
But there is a good reason to use Peano numbers in our case:
117
+
In the subsequent compilation steps we want to be able to do pattern matching on the indices. This is not possible with integers but it is possible with Peano numbers, because they are defined as an algebraic data type:
118
+
119
+
```haskell
120
+
dataPeano=SuccPeano | Zero
121
+
```
122
+
123
+
Now we'll take a look at the next step in the compilation process.The function `convert` translates the de Bruijn notation to a datatype `CL` which represents the combinator terms.
0 commit comments