Vitor's thoughts

Is Data Struct about memory?

Sun, 27 Aug 2023 00:00:00 GMT

A principle that I try to follow is to think about obvious concepts. Since we are introduced to society, we meet with a lot of concepts that we don't even question. Some authoritary figure like a teacher or a parent tells us things that we just accept.

If you think about data structure, you can relate it immediately to memory. Today, I want to discuss why data structures are not only about memory.

Introduction

For instance, let’s understand that we do not have any problem thinking about data structures to organize data in memory. The problem is never the idea that data structures are indifferent to implementation.

Data Structure is a way to organize, manage, and store data (yes, you can store things in math. If you think about matrices or sets, you can notice that is a way to organize data. In practice, store things is about to organize things). It is a collection of values that we can realize operations. In essence, it is an Algebraic Structure of data.

Algebraic Structure

An algebraic Structure is a set of elements with one or more operations that satisfy some specific properties (axioms). An example is Boolean Algebra, a set with two binary operations, union and intersection. You can follow this link to understand more about Boolean Algebra.

At this point, I want to highlight that algebraic structures are essentially about math. It describes the properties of a set of elements: a group, a ring, an algebra, etc. If you want to dive into this topic, read Algebraic Structures.

It is a big mistake to take an abstract and mathematical concept and reduce it to a simple implementation that needs physical and limited resources. You do not need any computer or memory to understand or use data structures. You need data. And data in math is just a set of elements.

Let's to think about computational models

The root of this problem is that you maybe don't know about computational models. It is a important step because if you think that in computer science we are using math to model computational problems, and computational problems are mathematical problems, you probably never will reduce any computational problem to a phisical and limited resource (like memory).

Computer science problems follow math problems, and we use math to model them. It means that the problem that you're trying to solve, can be modeled by a mathematical problem before you start to think about some computational implementation.

Conclusion

I hope that you understand that data structures are not only about memory. It is a mathematical concept that we use to model computational problems.

This text is a little talk about some ideas that I would like to share. I tried to give some references to help if you want to dive into this topic. Also, it's very important to think about obvious concepts and try to understand why the things are the way they are.

Introduction to Big O notation

Sat, 12 Aug 2023 00:00:00 GMT

Introduction

In this post, we will explore the concept of algorithm efficiency and how to measure this efficiency using big O notation. Additionally, we will see how this can help us write more performance code. Big O notation allows us to evaluate the performance of an algorithm according to the size of its data set.

What is big O notation and algorithm efficiency?

Algorithm efficiency is the ability to solve a problem in a reasonable time and with efficient use of computational resources such as processing and memory. Big O notation is a way of measuring the efficiency of an algorithm, describing the asymptotic behavior of a function. This means that we can evaluate the rate of growth of the function, comparing it to other algorithms.

Big O notation is represented by the letter O and is used as follows: Θ(f(n)), where f(n) is the measure by which the size of the input (n) increases. For example, an algorithm that grows quadratically, that is, increases proportionally to the square of each additional input, is represented by Θ(n²).

Constant time: Θ(1)
Linear time: Θ(n)
Logarithmic time: Θ(log(n))
Quadratic time: Θ(n²)

Big O notation in code

Suppose you have a list and need to find a certain element 'x'. This algorithm is called sequential search.

Another example is when you need to sort a list. This algorithm is called insertion sort.

Sequential search example

// linear time
function sequentialSearch(arr: number[], x: number) {
  for (let i = 0; i < arr.length; i++) {
    if (arr[i] === x) {
      return i
    }
  }
  return -1
}

Insertion sort example

// quadratic time
function insertionSort(arr: number[]) {
  for (let i = 1; i < arr.length; i++) {
    let currentVal = arr[i]
    for (var j = i - 1; j >= 0 && arr[j] > currentVal; j--) {
      arr[j + 1] = arr[j]
    }
    arr[j + 1] = currentVal

    console.log(arr)
  }

  return arr
}

Both codes work and solve the proposed problem, but one is more performative than the other. The first code is linear, which means that the for loop will be executed a number of times directly proportional to the size of the array. This means that if the array has n elements, the loop will be executed n times, which can be represented by Θ(n).

The advantage of this approach is that, in case of larger arrays, the code will run faster, as the number of iterations is proportional to the size of the array. This makes the time complexity of the code limited by the size of the array, resulting in a less steep growth chart compared to a code with quadratic complexity. In other words, the first code is more performative and efficient in situations where the array can be very large.

The second code is an example of quadratic complexity Θ(n²). This means that the for loop inside the for loop will be executed a number of times proportional to the square of the size of the array. In other words, if the array has n elements, the inner loop will be executed n * n times, which can be represented by Θ(n²).

The implications of this complexity are that, in larger arrays, the growth chart will be steeper, resulting in slower and more complex code as the input gets larger.

Now, let's see some examples of code with logarithmic complexities O(log(n)) and O(n log(n)).

Suppose you receive a list of numbers and need to find a certain number x in the list. To do this, you can use the binary search algorithm, which has complexity O(log(n)).

Another example is when you need to sort a list of numbers in a logarithmic way. To do this, you can use the merge sort algorithm, which has complexity O(n log(n)).

These algorithms are more performative and efficient than linear or quadratic approaches in situations where the size of the input can be very large.

Binary search example

// O(log(n))
function binarySearch(arr: number[], x: number) {
  let left = 0
  let right = arr.length - 1

  while (left <= right) {
    let mid = Math.floor((left + right) / 2)
    if (arr[mid] === x) {
      return mid
    }
    if (arr[mid] < x) {
      left = mid + 1
    } else {
      right = mid - 1
    }
  }
  return -1
}

Merge sort example

// O(n log(n))
function mergeSort(arr: number[]) {
  if (arr.length === 1) {
    return arr
  }

  let mid = Math.floor(arr.length / 2)
  let left = arr.slice(0, mid)
  let right = arr.slice(mid)

  return merge(mergeSort(left), mergeSort(right))
}

function merge(left: number[], right: number[]) {
  let result = []
  let i = 0
  let j = 0

  while (i < left.length && j < right.length) {
    if (left[i] < right[j]) {
      result.push(left[i])
      i++
    } else {
      result.push(right[j])
      j++
    }
  }

  return result.concat(left.slice(i)).concat(right.slice(j))
}

Both examples are valid, but they have different time complexities. The first one is O(log(n)), which means that the running time increases logarithmically with respect to the size of the input. In other words, in the worst case, if the array has 8 elements, the algorithm will be executed 3 times. For example: log2(8) = 3.

The second example, O(n log(n)), is a notation that indicates that the running time of an algorithm increases proportionally to the product of the size of the input data and the logarithm of that size. This means that, in the worst case, if the array has 8 elements, the algorithm will be executed 24 times. For example: 8 * log2(8) = 24.

However, it is important to remember that the temporal complexity of an algorithm does not necessarily imply higher or lower speed. It is possible that an algorithm with worse complexity is faster than an algorithm with better complexity, depending on the specific input. However, in general, it is safe to say that the lower the complexity, the faster the algorithm will be, as the input increases.

For those who want to delve deeper into the subject, I recommend reading the book “Introduction to Algorithms” by Thomas H. Cormen.

Proving natural numbers are infinity in Coq

Sun, 13 Aug 2023 00:00:00 GMT

Introduction

An interesting fact about math is that you can demonstrate things. A lot of people thinks that demonstrate is exemplify something, but it is not. It's common to see people saying that $1 + 1 = 2$, just like one apple plus one apple is two apples. But, this is not a demonstration. A demonstration is a logical proof that something is true, by a formal way. You cannot say that every 1 plus itself is equal to two. Boolean algebra is a good example of this. In Boolean algebra, $1 + 1 = 1$. So, you can't say that aways $1 + 1 = 2$.

What is Coq?

Coq is a software that allows you to write proofs. It is a proof assistant based on the calculus of inductive constructions. It is a functional programming language based on lambda calculus. I won't talk about lambda calculus and the calculus of inductive constructions, but you can find more information about them on Wikipedia.

What is a formal proof?

A formal proof is a process based on logical rules and axioms used to demonstrate some theorem. The goal is to show an absolute truth that some affirmation is faithful by following strict rules.

The proof

A simple way to prove that natural numbers are infinite is by defining that given a natural number ($n: nat$), $n + 1$ will return natural numbers greater than $n$.

You need to make it because this theorem proves that natural numbers are infinite by showing that given any natural numbers, you can always find a natural number greater than it, by summing $1$ to it.

So, lets to define our theorem in Coq:

Theorem plus_1_natural : forall n : nat, 1 + n = S n /\ S n > n.

The forall keyword means the theorem is valid for all natural numbers. The $\land$ means the theorem is a conjunction, and the $S$ is the successor function. So, the theorem says that given a natural number $n$, $1 + n$ is equal to $S n$, and $S n$ is greater than $n$.

Lets to prove the theorem:

Proof.
  intros n.
  split.
  - reflexivity.
  - apply le_n_S. apply le_n.
Qed.

intros n introduces the universal quantifier forall and the arbitrary natural number $n$ as a variable. The split. splits the objective into two subgoals. One for each conjunct $\land$. The hyphen is to refer to the subgoal. The reflexivity. is to prove that something equals to itself. Like $1 + n = S n$, because $1 + n$ is equal to $S n$. You can reduce it, like:

$1 + 1 = 2$.
$2 = 2$.

Coq have some macros that abstracts some proofs. We can see this reducing using simpl.:

Coq gives us some theorems related to natural numbers ordering, like le_n_S and le_n. These theorems can be used to reduce steps of our proof, replacing them with the applied theorem. In math, the le it is $\leq$, less than or equal.

le_n any natural number is less than or equal to itself. $n \leq n$ is a true statement for any natural number $n$.
le_n_S says that if $n \leq m$, then $S n \leq S m$. So, if $n \leq n$, then $S n \leq S n$.

The apply le_n_S. definition is le_n_S : forall n m : nat, n <= m -> S n <= S m, and le_n that le_n : forall n : nat, n <= n. So, to read the apply le_n_S. apply le_n. is: "Given a natural number n, if n <= n, then S n <= S n". And this is true, because n <= n is true, and S n <= S n is true too. So, the theorem is proved. Qed. means that the proof is finished.

You can also see it on CoqIDE:

Conclusion

You can also show the output of the proof and run the proof. So, lets do it.

You can use Print to show the definition of some theorem, and Eval compute in to run the proof. In the end, our proof will be:

Theorem plus_1_natural : forall n : nat, 1 + n = S n /\ S n > n.
Proof.
  intros n.
  split.
  - reflexivity.
  - apply le_n_S. apply le_n.
Qed.
Print plus_1_natural.
Eval compute in (plus_1_natural 1).

And the output will be:

plus_1_natural = fun n : nat => conj eq_refl (le_n_S n n (le_n n))
: forall n : nat, 1 + n = S n /\ S n > n

= plus_1_natural 1
: 1 + 1 = 2 /\ 2 > 1

Building a JSON Parser from scratch with JS

Sat, 12 Aug 2023 00:00:00 GMT

Introduction

A parser can have various applications in everyday life, and you probably use some parser daily. Babel, webpack, eslint, prettier, and jscodeshift. All of them, behind the scenes, run a parser that manipulates an Abstract Syntax Tree (AST) to do what you need - we'll talk about that later, don't worry.

The idea of this text is to introduce the concept of lexing and parsing, implementing them using JavaScript to analyze expressions in JSON. The goal will be to separate this process into functions, explain these functions, and, in the end, have you implement a JSON parser generating an AST.

It's worth noting that my repository is open, and you can access it here.

Lexing

A lexer will be responsible for converting an expression, whatever it may be, into tokens. These tokens are identifiable elements that have an assigned meaning.

You can divide these tokens in several ways, such as identifier, keyword, delimiter, operator, literal, and comment.

{ "type": "LEFT_BRACE", "value": undefined } is an example of a delimiter. { "type": "STRING", "value": "name" } is an example of a literal.

Example: {"name":"Vitor","age":18}

[
  { "type": "LEFT_BRACE", "value": undefined },
  { "type": "STRING", "value": "name" },
  { "type": "COLON", "value": undefined },
  { "type": "STRING", "value": "Vitor" },
  { "type": "COMMA", "value": undefined },
  { "type": "STRING", "value": "age" },
  { "type": "COLON", "value": undefined },
  { "type": "NUMBER", "value": "18" },
  { "type": "RIGHT_BRACE", "value": undefined }
]

Note that in lexical analysis, you separate your expression into tokens, and each token has its identification.

To code this, let's first understand what we will be doing exactly. The idea of the lexer function is to receive an argument of type String and return an Array of tokens, which will be our JSON divided into specific types of information, as we have already seen and discussed.

To achieve this, we will create a variable called current, which will store the current position of the character in the input being analyzed by the lexer. In other words, it represents the position it is currently at in our JSON. Additionally, we will have a constant called tokens, which will be an array that will hold all of our tokens in the end.

export const lexer = (input: string): Token[] => {
let current = 0;
const tokens: Token:[] = [];


}

Now, we need to run a loop that will iterate until all the characters of the input have been processed.

Note that it's possible to refactor all these if blocks into a switch statement. However, I followed an imperative style.

export const lexer = (input: string): Token[] => {
  let current = 0
  const tokens: Token[] = []


  while (current < input.length) {
    let char = input[current]


    if (char === '{') {
      tokens.push(createToken(TOKEN_TYPES.LEFT_BRACE))
      current++
      continue
    }


    if (char === '}') {
      tokens.push(createToken(TOKEN_TYPES.RIGHT_BRACE))
      current++
      continue
    }


    if (char === '[') {
      tokens.push(createToken(TOKEN_TYPES.LEFT_BRACKET))
      current++
      continue
    }


    if (char === ']') {
      tokens.push(createToken(TOKEN_TYPES.RIGHT_BRACKET))
      current++
      continue
    }


    if (char === ':') {
      tokens.push(createToken(TOKEN_TYPES.COLON))
      current++
      continue
    }


    if (char === ',') {
      tokens.push(createToken(TOKEN_TYPES.COMMA))
      current++
      continue
    }


    const WHITESPACE = /\s/


    if (WHITESPACE.test(char)) {
      current++
      continue
    }


    const NUMBERS = /[0-9]/
    if (NUMBERS.test(char)) {
      let value = ''
      while (NUMBERS.test(char)) {
        value += char


        char = input[++current]
      }
      tokens.push(createToken(TOKEN_TYPES.NUMBER, value))
      continue
    }


    if (char === '"') {
      let value = ''
      char = input[++current]
      while (char !== '"') {
        value += char
        char = input[++current]
      }
      char = input[++current]
      tokens.push(createToken(TOKEN_TYPES.STRING, value))
      continue
    }


    if (
      char === 't' &&
      input[current + 1] === 'r' &&
      input[current + 2] === 'u' &&
      input[current + 3] === 'e'
    ) {
      tokens.push(createToken(TOKEN_TYPES.TRUE))
      current += 4
      continue
    }


    if (
      char === 'f' &&
      input[current + 1] === 'a' &&
      input[current + 2] === 'l' &&
      input[current + 3] === 's' &&
      input[current + 4] === 'e'
    ) {
      tokens.push(createToken(TOKEN_TYPES.FALSE))
      current += 5
      continue
    }


    if (
      char === 'n' &&
      input[current + 1] === 'u' &&
      input[current + 2] === 'l' &&
      input[current + 3] === 'l'
    ) {
      tokens.push(createToken(TOKEN_TYPES.NULL))
      current += 4
      continue
    }


    throw new TypeError('I dont know what this character is: ' + char)
  }


  return tokens
}

This code may seem complicated, but it's actually quite simple. Inside my loop, I start by defining the variable char, which will store the character currently being analyzed in that iteration of the loop. Then, for each type of character, we want a specific action.

If the char is equal to {, we push into the tokens array, passing to it the ENUM of Tokens, which will be the name of each token.

export enum TOKEN_TYPES {
  LEFT_BRACE = 'LEFT_BRACE',
  RIGHT_BRACE = 'RIGHT_BRACE',
  LEFT_BRACKET = 'LEFT_BRACKET',
  RIGHT_BRACKET = 'RIGHT_BRACKET',
  COLON = 'COLON',
  COMMA = 'COMMA',
  STRING = 'STRING',
  NUMBER = 'NUMBER',
  TRUE = 'TRUE',
  FALSE = 'FALSE',
  NULL = 'NULL',
}

In the function createToken, it only returns an object with the type or value if it exists.

export const createToken = (type: TOKEN_TYPES, value?: string): Token => {
  return {
    type,
    value,
  }
}

After that, it increments +1 to the current variable to move to the next char in our string. This process is quite repetitive and straightforward. I won't explain each one of them, but it's worth paying attention to those that deviate a bit from the pattern.

if (char === '"') {
  let value = ''
  char = input[++current]
  while (char !== '"') {
    value += char
    char = input[++current]
  }


  char = input[++current]
  tokens.push(createToken(TOKEN_TYPES.STRING, value))
  continue
}


if (
  char === 't' &&
  input[current + 1] === 'r' &&
  input[current + 2] === 'u' &&
  input[current + 3] === 'e'
) {
  tokens.push(createToken(TOKEN_TYPES.TRUE))
  current += 4
  continue
}


if (
  char === 'f' &&
  input[current + 1] === 'a' &&
  input[current + 2] === 'l' &&
  input[current + 3] === 's' &&
  input[current + 4] === 'e'
) {
  tokens.push(createToken(TOKEN_TYPES.FALSE))
  current += 5
  continue
}


if (
  char === 'n' &&
  input[current + 1] === 'u' &&
  input[current + 2] === 'l' &&
  input[current + 3] === 'l'
) {
  tokens.push(createToken(TOKEN_TYPES.NULL))
  current += 4
  continue
}

If the char is equal to ", we enter a loop to continue reading the subsequent characters until we find another quotation mark, as this indicates the end of the string. All the characters read during this loop are concatenated into the "value" variable. Then, a new token is added to the "tokens" array.

The other lines are used to set boolean values. If the current character is "f" and the subsequent characters form the word false, we add false to the tokens array. The same process is repeated for true.

In all cases, the current variable is incremented to point to the next character to be processed, just like we did throughout the rest of our code.

Parsing

A parser is responsible for transforming a sequence of tokens into a data structure, in this case, an AST.

Illustration of an AST taken from the book "Modern Compiler Implementation in ML."

An Abstract Syntax Tree (AST) is a data structure that represents the syntactic structure of a program. Within the AST, there are several nodes, and each node represents a valid syntactic construct of the program. For example:

parser: {
  "type": "Program",
  "body": [
    {
      "type": "ObjectExpression",
      "properties": [
        {
          "type": "Property",
          "key": {
            "type": "STRING",
            "value": "name"
          },
          "value": {
            "type": "StringLiteral",
            "value": "Vitor"
          }
        },
        {
          "type": "Property",
          "key": {
            "type": "STRING",
            "value": "age"
          },
          "value": {
            "type": "NumberLiteral",
            "value": "18"
          }
        }
      ]
    }
  ]
}

This is the AST of the JSON I exemplified at the beginning. In this example, we have a total of 8 nodes. The Program node represents the main program. ObjectExpression represents an object, Property represents a property within an object, consisting of a key and a value. STRING represents a string used as a key, StringLiteral represents a string within a property, and NumberLiteral represents a numeric value within a property.

Through an AST, it's possible to optimize code, transform one code into another, perform static analysis, generate code, and more. For example, you could implement a new syntax, create a parser, and generate JavaScript code that would execute normally.

To generate our AST, we will need a function that receives our array of tokens, iterates through it, and generates the AST according to the tokens it encounters. For this purpose, we will create a function called walk, which will traverse the tokens and return the nodes of the AST.

export const parser = (tokens: Array<{ type: string; value?: any }>) => {
    let current = 0;


    const walk = () => {
        let token = tokens[current];


        if (token.type === TOKEN_TYPES.LEFT_BRACE) {
            token = tokens[++current];


            const node: {
                type: string;
                properties?: Array<{ type: string; key: any; value: any }>;
            } = {
                type: 'ObjectExpression',
                properties: [],
            };


            while (token.type !== TOKEN_TYPES.RIGHT_BRACE) {
                const property: { type: string; key: any; value: any } = {
                    type: 'Property',
                    key: token,
                    value: null,
                };


                token = tokens[++current];


                token = tokens[++current];
                property.value = walk();
                node.properties.push(property);


                token = tokens[current];
                if (token.type === TOKEN_TYPES.COMMA) {
                    token = tokens[++current];
                }
            }


            current++;
            return node;
        }

The first check we perform is whether the current token is {. If it is, we create a new node of type ObjectExpression and iterate through the following tokens, adding them as properties of the object until we find the end of the key, which is }. Each property is represented by a node of type Property. This Property type has a value that is generated by the walk() function, which is called recursively.

Note that I use tokens[++current]. This is to advance the cursor to the next token. And if a token of type , (comma) is found, we advance the cursor again to skip the comma.

The rest of the code is quite similar to what I've just explained, so it's worth the effort to look and try to understand or implement the rest on your own. It's not very complex.

Finally, I create the constant ast, which will contain the type Program and the body of the AST, generated by the walk() function. The while loop ensures that current does not exceed the size of the tokens array.

After that, we simply return the AST.

export const parser = (tokens: Array<{ type: string; value?: any }>) => {
  let current = 0


  const walk = () => {
    let token = tokens[current]


    if (token.type === TOKEN_TYPES.LEFT_BRACE) {
      token = tokens[++current]


      const node: {
        type: string
        properties?: Array<{ type: string; key: any; value: any }>
      } = {
        type: 'ObjectExpression',
        properties: [],
      }


      while (token.type !== TOKEN_TYPES.RIGHT_BRACE) {
        const property: { type: string; key: any; value: any } = {
          type: 'Property',
          key: token,
          value: null,
        }


        token = tokens[++current]


        token = tokens[++current]
        property.value = walk()
        node.properties.push(property)


        token = tokens[current]
        if (token.type === TOKEN_TYPES.COMMA) {
          token = tokens[++current]
        }
      }


      current++
      return node
    }


    if (token.type === TOKEN_TYPES.RIGHT_BRACE) {
      current++
      return {
        type: 'ObjectExpression',
        properties: [],
      }
    }


    if (token.type === TOKEN_TYPES.LEFT_BRACKET) {
      token = tokens[++current]


      const node: {
        type: string
        elements?: Array<{ type?: string; value?: any }>
      } = {
        type: 'ArrayExpression',
        elements: [],
      }


      while (token.type !== TOKEN_TYPES.RIGHT_BRACKET) {
        node.elements.push(walk())
        token = tokens[current]


        if (token.type === TOKEN_TYPES.COMMA) {
          token = tokens[++current]
        }
      }


      current++
      return node
    }


    if (token.type === TOKEN_TYPES.STRING) {
      current++
      return {
        type: 'StringLiteral',
        value: token.value,
      }
    }


    if (token.type === TOKEN_TYPES.NUMBER) {
      current++
      return {
        type: 'NumberLiteral',
        value: token.value,
      }
    }


    if (token.type === TOKEN_TYPES.TRUE) {
      current++
      return {
        type: 'BooleanLiteral',
        value: true,
      }
    }


    if (token.type === TOKEN_TYPES.FALSE) {
      current++
      return {
        type: 'BooleanLiteral',
        value: false,
      }
    }


    if (token.type === TOKEN_TYPES.NULL) {
      current++
      return {
        type: 'NullLiteral',
        value: null,
      }
    }


    throw new TypeError(token.type)
  }


  const ast = {
    type: 'Program',
    body: [],
  }


  while (current < tokens.length) {
    ast.body.push(walk())
  }


  return ast
}

const tokens = lexer('{"name":"Vitor","age":18}')
console.log('tokens', tokens)
const json = parser(tokens)


console.log('parser:', JSON.stringify(json, null, 2))

Parsing can be fun, but in reality, it's not often written, and you probably don't need to write your own parser. If you are implementing a programming language, for example, there are already various tools that can do this job for you, such as OCamllex, Menhir, or Nearley.

It's also essential to note that, as this is an introductory article, I didn't cover the different tokenization and parsing techniques, such as LR(0), LR(1), SLR(1), etc. However, be aware that these techniques exist, and you can research more about them. There are also many books that cover these topics.

If you want to see how the AST of popular languages looks, I recommend the AST Explorer. It supports various languages, and you can view the complete AST and navigate through the nodes. If you want to go further, you can try to copy some logic from an existing parser and implement it in your own, such as calculating an expression according to precedence order, for example: 1 + 2 * 3 (which is 7, not 9).

If you're interested in learning more, I recommend the book "Modern Compiler Implementation in ML." Despite the title being in ML, you can study from it without necessarily writing ML code, as there are other versions written in C, C++, and Java.

Introduction to Machine Code

Sun, 03 Nov 2024 00:00:00 GMT

What is machine code?

Machine code is computer code.

It consisting of machine language instructions that will be used to control a CPU. And about this, the reason that some programming languages have virtual machines, is to simulate a unique CPU. It helps to run the same code on different platforms without needing to care about specific architectures.

An opcode (Operation Code) is one byte wide, has an arbitrary but unique value, and is the first byte on the instruction.

Opcodes are just a set that specifies the operation (op) to be performed. In other words, an opcode is just an instruction machine code.

Example:

MOV AL, 34h

The opcode here is the MOV instruction. The other parts are the operands. In this case, the operands are the register AL and the value 34 hex. However, the operands are the parameters for the instruction. If it needs clarification, it could be more helpful to think about math. Think about 3 + 6 = 9. The "opcode" here, the operation, is the + symbol, which means addition. The operands are 3 and 6.

Assembler, disassembler

Of course, no one writes code in machine code — at least not in modern times. However, some tools translate code from Assembly Language to Machine Code.

In assembly language, each instruction on the computer is represented by a mnemonic:

section .data
	    msg db "Result: "         ; message to display
    number db '0'                 ; single character to store the result

section .text
    global _start

_start:
    mov rax, 1                    ; Put number 1 in rax
    add rax, 2                    ; Add 2 to it

    ; Step 2: Convert result to character
    add rax, '0'                  ; Convert number to ASCII character
    mov [number], al              ; Store the character

    ; Step 3: Print "Result: "
    mov rax, 1                    ; System call for write
    mov rdi, 1                    ; File descriptor 1 is stdout
    mov rsi, msg                  ; Address of our message
    mov rdx, 8                    ; Message length
    syscall

    ; Step 4: Print the number
    mov rax, 1                    ; System call for write
    mov rdi, 1                    ; File descriptor 1 is stdout
    mov rsi, number               ; Address of our number
    mov rdx, 1                    ; Length is 1 character
    syscall

    ; Step 5: Exit program
    mov rax, 60                   ; System call for exit
    xor rdi, rdi                  ; Return code 0
    syscall

This code was written using an assembler/disassembler called NASM and sums 1 to 2. This program (NASM) will translate the mnemonics into machine code. Historically, this part is exciting. If you think about how things work nowadays, we already have compilers and all the tools needed to write code that humans can easily understand. But think a second about the process of creating a new programming language.

Of course, you will need some language to code your new language. For example, I'm writing a toy language called Monkey using GoLang. If you're creating a language for production use, eventually, you'll do the bootstrapping — basically, implement your language using the language itself. Following my example of Monkey, it is like refactoring Monkey using Monkey instead of GoLang.

Now, moving some years back, someone needed to write the first assembler/disassembler directly in a binary system. The first functional computer will depend on what you understand by computer and functional and other things. But I'll follow the idea that it was the EDSAC. Initially, from binary input, programs were entered using a set of 18 switches on EDSAC's control panel. Each instruction was typically 18 bits long - that's not 18 because the topmost was always unavailable due to timing programs, so only 17 bits were used. Operators would physically flip these switches to represent 1s and 0s. And, of course, they used paper tape for program storage, but the initial loader had to be entered manually. Then, the first simple assembler. This was a tiny 31-instruction program (31 words). It was the world's first assembler. It could read paper tape and convert simple symbolic notations into machine code. The basic format was like a Letter + Number, like A 32, which means "Add the content of memory location 32".

The first bootstrap comes from this basic assembler. The new version could handle more symbols, basic arithmetic in the address, and some macros. This process was repeated. If you want to learn more about this, I recommend reading EDSAC from Wikipedia and watching Bootstrapping EDSAC: Initial Orders—Computerphile from Computerphile.

Starting with bytes

Excellent. I hope I have cleared your mind about machine code at this point. We'll write some code in GoLang to write our machine code instructions.

Let's start by defining the bytecode format:

package code

type Instructions []byte // byte is an alias for uint8

type Opcode byte

Instructions are a slice of bytes, and an Opcode is a byte. Note how it describes our past descriptions. Let's define the first opcode, which would tells the VM (or the processor, if you're compiling directly to machine code and to some especific processor architecture) to push something on the stack - we'll not build a VM at this article.

Backing to the opcode, it wouldn't be called "push", because it won't be solely about pushing things. Let's think about the expression 1 + 2. There are three instructions, two of which tell the VM/processor to push 1 and 2 to the stack. A first instinct might tell us to implement these by defining a "push" instruction with an integer as its operand, with the idea being that the VM/processor then takes the integer operand and pushes it into the stack. For integers, it would work because I could encode them and put them directly into the bytecode, but for string literals, for example, putting those into the bytecode is also possible since it's just made of bytes. Still, it would also be a lot of bloat and would sooner or later become unwieldy.

Variable size: A string can be any length, like "a" or "a more extensive text like this one.";
You'd have multiple copies of the same string if it appears several times;
Bytecode loading performance would be impacted;

Notice how it is a bad design? Here, I introduce the idea of constants.

Constants

In this context, constants are short for "constant expressions" and refer to expressions whose value doesn't change. It is constant and can be determined at compile time. That means we don't need to run the program to know what these expressions evaluate. A compiler can find them in the code and store the value they evaluate. After that, it can reference the constants in the instructions it generates instead of embedding the value directly in them. A plain integer does the job fine and can serve as an index into a data structure that holds all constants, often called a constant pool. For example:

// Instead of having bytecode like:
PUSH 987654321 // Takes up a lot of space if the number is big
PUSH "Hello World" // Takes even more space for string

// I can have:
PUSH_CONST 0 // Where 0 is just an index into the constant pool
PUSH_CONST 1 // Much more compact

Constant Pool:
[0] -> 987654321
[1] -> "Hello World"

More compact bytecode (indices are smaller than full values)
Deduplication (the same constant only needs to be stored once)
Better memory usage
It is easier to manage complex constants like strings

Well, that said, let's define the OpConstant. This opcode has one operand: the number I previously assigned to the constant. When the VM/processor executes OpConstant, it retrieves the constant using the operand as an index and pushes it on to the stack.

// [...]

const (
	OpConstant Opcode = iota
)

Iota will generate increasing byte values because I don't care about the actual values the opcodes represent. They only need to be distinct from each other and fit in one byte. Now, let's define the part that says OpConstant has one operand.

// [...]

type Definition struct {
	Name          string
	OperandWidths []int
}

var definitions = map[Opcode]*Definition{
	OpConstant: {"OpConstant", []int{2}},
}

func Lookup(op byte) (*Definition, error) {
	def, ok := definitions[Opcode(op)]
	if !ok {
		return nil, fmt.Errorf("opcode %d undefined", op)
	}
	return def, nil
}

The lookup helper is not needed, but it's nice for debugging:

debug, _ := Lookup(instructions[0])
fmt.Println(debug)

Output:

go test ./code -v
=== RUN   TestMake
&{OpConstant [2]}
--- PASS: TestMake (0.00s)
PASS
ok      github.com/vit0rr/introduction-to-machine-code/code     0.179s

The Definition for an Opcode has two fields: Name and OperandsWidths. Name helps to make an Opcode readable and OperandWidths contains the number of bytes each operand takes up.

The definition for OpConstant says that it's only operand two bytes wide, which makes it an uint16 and limits its maximum value to 65535; if it includes 0, the number of representable values is then 65536.

With this, It's already possible to create the first bytecode instruction - finally.

// [...]

func Make(op Opcode, operands ...int) []byte {
	def, ok := definitions[op]
	if !ok {
		return []byte{}
	}

	instructionLen := 1
	for _, w := range def.OperandWidths {
		instructionLen += w
	}

	instruction := make([]byte, instructionLen)
	instruction[0] = byte(op)

	offset := 1
	for i, o := range operands {
		width := def.OperandWidths[i]
		switch width {
		case 2:
			binary.BigEndian.PutUint16(instruction[offset:], uint16(o))
		}
		offset += width
	}

	return instruction
}

This function creates a bytecode instruction for the given Opcode and operands. It looks up the Definition for the Opcode and calculates the instruction's length. Then it creates a byte slice with the correct length and sets the first byte to the Opcode. The function then iterates over the operands, encoding them into the instruction according to their width.

And of course we'll write tests about all this.

package code

import "testing"

func TestMake(t *testing.T) {
	tests := []struct {
		op       Opcode
		operands []int
		expected []byte
	}{
		{OpConstant, []int{65534}, []byte{byte(OpConstant), 255, 254}},
	}

	for _, tt := range tests {
		instructions := Make(tt.op, tt.operands...)

		if len(instructions) != len(tt.expected) {
			t.Errorf("instructions has wrong length. want=%d, got=%d",
				len(tt.expected), len(instructions))
		}

		for i, b := range tt.expected {
			if instructions[i] != tt.expected[i] {
				t.Errorf("wrong byte at pos %d. want=%d, got=%d",
					i, b, instructions[i])
			}
		}
	}
}

I only pass OpConstant and the operand 65534 to the Make function. Then expect to get back a []byte golding three bytes. The first has to be the opcode, OpConstant, and the other two should be the big-endian encoding of 65534. And that's also why use 65534 instead of 65535:

65534 in decimal = 1111 1111 1111 1110 in binary
                 = 0xFF 0xFE in hexadecimal (two bytes)

Big-endian means "most significant byte first". Like reading left-to-right:

In big-endian: 65534 = [0xFF, 0xFE]
In little-endian: 65534 = [0xFE, 0xFF] And 65535, both bytes are the same ([0xFF, 0xFF]) - can't tell the order.

The expected output is 3 bytes:

[OpConstant, 0xFF, 0xFE]
 ^           ^      ^
 |           |      Second byte of 65534
 |           First byte of 65534
 The instruction opcode

The first thing I'm doing here is to determine how long the resulting instruction will take. That allows me to allocate a byte slice with the proper length. Note that I don't use the Lookup function to get to the definition, which gives me a more usable function signature for Make in the tests later.

As soon as we have the final value of instructionLen, we allocate the instruction []byte and add the Opcode as its first byte by casting it into one. Then comes the tricky part: I iterate over the defined operand widths, taking the matching element from operands and putting it in the instructions. Depending on its width, I do that by using a switch statement with a different method for each operand.

I only ensure that a two-byte operand is encoded in big-endian. After encoding the operand, I increment the offset by its width and the next iteration of the loop. Since the OpConstant opcode in the test case has only one operand, the loop performs only one iteration before the Make returns instruction.

And that's it! First bytecode instruction is done.

go test ./code
ok      github.com/vit0rr/introduction-to-machine-code/code     0.537s

References:

Introduction to the Untyped Lambda Calculus (β-reduction and α-conversion)

Tue, 04 Nov 2025 00:00:00 GMT

Lambda calculus is a simple programming language, and a model of computation (akin to Turing machines and recursive functions).

It's composed only of abstractions and applications using variables (e.g. (λx.x) y). The whole language is made up of lambda terms.

Lambda terms can be one of these three things:

A variable like x is a valid lambda term.
An abstraction (λx.y), or (λx.t), where x is it's variable and y/t is another lambda term. (λx.x) could be written in JS as const id = x => x. Everything after the dot works as the body of a function, so you could read λx as a function receiving x as variable. That's why (λx.x) is what we call identity function, becase it returns what it receives.
An application (t s) where both t and s are lamba terms.

Since lambda calculus has only functions, we use church encoding to model arithmetic, booleans and data structures by representing data types in the lambda calculus.

Church numerals let you represent natural numbers under Church encoding:

0 := λf.λx. x
1 := λf.λx. f x
2 := λf.λx. f (f x)
3 := λf.λx. f (f (f x))

Each numeral is a function that takes two arguments, f and x, and applies f n times to x. That's how we know what is each number, by couting how many times f was applied to x.

It is just a higher-order function, in Javascript it would look like this:

const zero = f => x => x
const one = f => x => f(x)
const two = f => x => f(f(x))
const three = f => x => f(f(f(x)))

If you're not familiar with the notation, you can read it as giving a function f, and a value x, apply f to x.

A successor function is quite similar. Since two is x applied to f two times, to know it's successor, you should apply f one more time. So, given a numeral n, it returns a numeral that applies f (n+1) times.

succ := λn.λf.λx.f (n f x)

Let's break it into small pieces, because it's not that easy to understand at the first time.

1 := λf.λx. f x
succ := λn.λf.λx. f (n f x)

(λn.λf.λx. f (n f x)) (λf.λx. f x)
    (λf.λx. f ((λf.λx. f x) f x)) // now it is a function that expects f and x
    |           (λx. f x) x
    |               f x
    (λf.λx. f (f x)) // it just becomes the definition of two

By reducing the full expression, we're now seeing why succ (1 λf.λx. f x) returns 2 (λf.λx. f (f x)).

It's possible to do the same for plus, mult, pow, pred, true, false, and, or, not, .... Church encoding can also be used to create a pair (2-tuple), lists with their common functions like head, tail, cons...

Evaluation and Reduction

The process of computing the value of a lambda term is what we call evaluation or reduction, and we will take a look at the β-reduction.

(λx.x + 1) 5
(5 + 1)
(6)

So we're applying a function to an argument by replacing the bound variable with that argument.

A more general rule could be defined as (λx. M) N → M[x := N]. Where M is the body of the abstraction, and N, it's argument. M[x := N] replaces all free instances of x, by N (I did a bunch of reductions by hand to understand well this process). But this rule requires alpha-conversion to avoid variable capure. It happens when a free variable in N becomes bound after substitution.

(λx. λy. x) y
     (λy. y)

It changed the meaning of our previous expression. the inner y in (λy. x) referred to the outer argument y. But after substitution, it became bound by the inner λy. So it no longer refers to the same variable

With alpha-conversion, we rename bound variables.

(λx. λy. x) y
(λx. λz. x) y
     (λz. y)

We're giving each scope a unique variable name.

AND TRUE FALSE
// remember TRUE λx.λy.x and FALSE λx.λy.y

(λp. λq. p q p) TRUE FALSE
     (λq. TRUE q TRUE) FALSE
     TRUE FALSE TRUE
     (λx. λy. x) FALSE TRUE
          (λy. FALSE) TRUE
               FALSE

Try to reduce AND, OR, NOT, IF, etc...

Starting the interpreter

Well, I think what we know until now is enough to at least start writing an interpreter.

Let's start defining the AST, which one is just a term:

type term = Var of string | Abs of string * term | App of term * term

I don't know if you who is reading this are familiar with OCaml, but it is just the type of a term, ... of type means that a type carries a value, so the type Var comes with a string value. If you wanna understand more about it, take a read about variant constructors and algebraic data type.

Var of string in a more practial use:

let x = Var "x"

Same of the others:

let abs = Abs ("x", Var "x")

As you probably have already noticed, this abs is the same as λx.x. It's possible to write a function to do this prettify for us. This function should receive a term, and transform it to string.

let rec to_string ~term =
  match term with
  | Var x -> x
  | Abs (x, body) -> "λ" ^ x ^ to_string ~term:body
  | App (t1, t2) -> to_string ~term:t1 ^ to_string ~term:t2

Nothing fancy, just a recursive function calling itself for terms. The ^ thing is how to concat strings in OCaml.

I'm using labeled arguments just because it is a tutorial and I wanna make it easier to read the code. Otherwise I would write it like this:

let rec to_string t =
  match t with
  | Var x -> x
  | Abs (x, body) -> "λ" ^ x ^ to_string body
  | App (t1, t2) -> to_string t1 ^ to_string t2

Take a look back at your defined term. I mentioned the of ... notation carries a value. We're using it's value on the pattern matching: Abs (x, body) -> "λ" ^ x ^ to_string ~term:body, where x is the string and body the term.

Now let's take a look at the output by writing an anonymous functions to call to_string

let () =
  let term = App (Abs ("x", Var "x"), Abs ("y", Var "y")) in
  let result = to_string ~term in
  print_endline result

Output:

> λxxλyy

That's still a bit weird, because it's missing the . and ():

let rec to_string ~term =
  match term with
  | Var x -> x
  | Abs (x, body) -> "λ" ^ x ^ "." ^ to_string ~term:body
  | App (t1, t2) -> "(" ^ to_string ~term:t1 ^ " " ^ to_string ~term:t2 ^ ")"

Output: (λx.x λy.y)

Seems good enough.

Now we need to reduce expressions. Let's recap the rule: (λx. M) N → M[x := N], so, given the body M, replace all free occurrences of x with N. Let's write it, but in OCaml.

The signature of what we gonna write: in_term:term -> variable:string -> by_term:term -> term, so subst ~in_term:M ~variable:"x" ~by_term:N:

let rec subst ~in_term ~variable ~by_term =
  match in_term with
  | Var v -> if v = variable then by_term else Var v
  | App (t1, t2) ->
      App
        ( subst ~in_term:t1 ~variable ~by_term,
          subst ~in_term:t2 ~variable ~by_term )
  | Abs (x, t) ->
      if x = variable then Abs (x, t)
      else Abs (x, subst ~in_term:t ~variable:x ~by_term)

To apply this rule, we also must write a reduce function, which gonna call subst, so we gonna substitute terms recursively. Also, worth remembering that we're doing normal-order reduction. It means we gonna reduce from left to right.

let rec reduce ~term =
  match term with
  | App (Abs (var, body), arg) -> subst ~in_term:body ~variable:var ~by_term:arg
  | App (lt, rt) ->
      let lt' = reduce ~term:lt in
      if lt <> lt' then App (lt', rt) else App (lt, reduce ~term:rt)
  | Abs (var, body) -> Abs (var, reduce ~term:body)
  | Var _ -> term

Again, idk how much you who are reding this knows about OCaml, so I want to explain a bit this code.

| App (Abs (var, body), arg): we want to check for the tradicional case. It matches for expressions like (λx.x) y. For this case, we can just call subst.
| App (lt, rt): now we need to handle things like ((λx.x)(λy.y))z. Since we're implementing a normal-order reduction, we gonna first reduce the lf (left term). <> in OCaml compares two structures, so we're checking if lt and lt' differs, if so, we're returning an application, but with the left-term reduced. Otherwise, the left-term is already reduced, so we reduce the right one.
| Abs (var, body): nothing special, we're reducing the only available term to reduce.

Good, here's the code until now:

type term = Var of string | Abs of string * term | App of term * term

let rec to_string ~term =
  match term with
  | Var x -> x
  | Abs (x, body) -> "λ" ^ x ^ "." ^ to_string ~term:body
  | App (t1, t2) -> "(" ^ to_string ~term:t1 ^ " " ^ to_string ~term:t2 ^ ")"

let rec subst ~in_term ~variable ~by_term =
  match in_term with
  | Var v -> if v = variable then by_term else Var v
  | App (t1, t2) ->
      App
        ( subst ~in_term:t1 ~variable ~by_term,
          subst ~in_term:t2 ~variable ~by_term )
  | Abs (x, t) ->
      if x = variable then Abs (x, t)
      else Abs (x, subst ~in_term:t ~variable:x ~by_term)

let rec reduce ~term =
  match term with
  | App (Abs (var, body), arg) -> subst ~in_term:body ~variable:var ~by_term:arg
  | App (lt, rt) ->
      let lt' = reduce ~term:lt in
      if lt <> lt' then App (lt', rt) else App (lt, reduce ~term:rt)
  | Abs (var, body) -> Abs (var, reduce ~term:body)
  | Var _ -> term

let () =
  let term = App (Abs ("x", Var "x"), Var "y") in
  let result = to_string ~term:(reduce ~term) in
  print_endline result

It prints to y, which is fine. But let's try to reduce this other expression: (λx.λy.x)y (let term = App (Abs ("x", Abs ("y", Var "x")), Var "y")). It prints λy.x, which is wrong, because we didn't implemented alpha-conversion yet. We need to fix our subst Abs (x, t) match case.

Let's write a function to check if a variable is free in a given term.

let rec free_in ~variable ~term =
  match term with
  | Var x -> x = variable
  | App (lt, rt) -> free_in ~variable ~term:lt || free_in ~variable ~term:rt
  | Abs (x, body) ->
      if x = variable then false else free_in ~variable:x ~term:body

We can check if a variable is free, but we still need to rename it somehow, so let's now write a function to create a new unique name:

let fresh_var =
  let counter = ref 0 in
  fun base ->
    incr counter;
    base ^ string_of_int !counter

This one is just a closure and we're creating unique variables by incrementing a counter, and than concating the variable with the counter. In OCaml, this ! means dereference. So we're getting the ref. value inside counter.

By refactoring subst, we should now check for free variables:

let rec subst ~in_term ~variable ~by_term =
  ...
  | Abs (x, t) ->
      if x = variable then Abs (x, t)
      else if free_in ~variable:x ~term:by_term then
        let x' = fresh_var x in
        let t' = subst ~in_term:t ~variable:x ~by_term:(Var x') in
        Abs (x', subst ~in_term:t' ~variable ~by_term)
      else Abs (x, subst ~in_term:t ~variable ~by_term)

The first if checks if the variable we want to substitute is the same as the one bound by the lambda. If they are equal, we don’t perform substitution inside, because within this lambda, that variable name refers to its parameter, not the outer variable we’re replacing.

Otherwise, we check if the x appears free in by_term. If so, we must rename that parameter before substituting.

Here's the full code:

type term = Var of string | Abs of string * term | App of term * term

let rec to_string ~term =
  match term with
  | Var x -> x
  | Abs (x, body) -> "λ" ^ x ^ "." ^ to_string ~term:body
  | App (t1, t2) -> "(" ^ to_string ~term:t1 ^ " " ^ to_string ~term:t2 ^ ")"

let rec free_in ~variable ~term =
  match term with
  | Var x -> x = variable
  | App (lt, rt) -> free_in ~variable ~term:lt || free_in ~variable ~term:rt
  | Abs (x, body) ->
      if x = variable then false else free_in ~variable ~term:body

let fresh_var =
  let counter = ref 0 in
  fun base ->
    incr counter;
    base ^ string_of_int !counter

let rec subst ~in_term ~variable ~by_term =
  match in_term with
  | Var v -> if v = variable then by_term else Var v
  | App (t1, t2) ->
      App
        ( subst ~in_term:t1 ~variable ~by_term,
          subst ~in_term:t2 ~variable ~by_term )
  | Abs (x, t) ->
      if x = variable then Abs (x, t)
      else if free_in ~variable:x ~term:by_term then
        let x' = fresh_var x in
        let t' = subst ~in_term:t ~variable:x ~by_term:(Var x') in
        Abs (x', subst ~in_term:t' ~variable ~by_term)
      else Abs (x, subst ~in_term:t ~variable ~by_term)

let rec reduce ~term =
  match term with
  | App (Abs (var, body), arg) -> subst ~in_term:body ~variable:var ~by_term:arg
  | App (lt, rt) ->
      let lt' = reduce ~term:lt in
      if lt <> lt' then App (lt', rt) else App (lt, reduce ~term:rt)
  | Abs (var, body) -> Abs (var, reduce ~term:body)
  | Var _ -> term

let () =
  let term = App (Abs ("x", Abs ("y", Var "x")), Var "y") in
  let result = to_string ~term:(reduce ~term) in
  print_endline result

And it evaluates to λy1.y now, which is the correct result. The interpreter is already doing beta-reduction and avoiding shadowing by applying alpha-conversion.

De Bruijn index

Named variables is kinda messy. Renaming variables, generating fresh ones, checking free vars... Even when two functions are structurally the same, if it is using different variables, our interpreter still treats them as different (e.g. λx. λy. x, λa. λb. a).

All this process is only used to indicate how far back their binder is.

De Bruijn indices drops all these names, and replace it with a number, indicating how far back their binder is: λx. λy. x -> λ. λ. 1 (for the closest binding). Try some exercicies converting from De Bruijn to named, and from named to De Breuijn.

λ. λ. λ. 3 (2 1) becomes λx. λy. λz. x (y z)

Refactoring

The AST has no variables anymore, so we gonna drop all string references:

type term = Var of int | Abs of term | App of term * term

let rec to_string ~term =
  match term with
  | Var i -> string_of_int i
  | Abs t -> "λ." ^ to_string ~term:t
  | App (t1, t2) -> "(" ^ to_string ~term:t1 ^ " " ^ to_string ~term:t2 ^ ")"

When we substitute a term into another, the indices can move depending on how many binders we cross, and that's why a shift function is needed, to fix the numbers when you relocate a term.

let rec shift ~by ~depth ~term =
  match term with
  | Var i -> if i >= depth then Var (i + by) else Var i
  | Abs t ->
      let depth' = depth + 1 in
      Abs (shift ~by ~depth:depth' ~term:t)
  | App (t1, t2) -> App (shift ~by ~depth ~term:t1, shift ~by ~depth ~term:t2)

The depth parameter tracks how many binders we've gone under. When we find a variable with index i >= depth, it means this variable refers to something outside our current context, so we need to adjust it by by amount.

If we have λ. 0 and want to insert it into another context, we need to shift its free variables so they still point to the right binders.

let rec subst ~index ~arg ~term =
  match term with
  | Var i -> if i = index then arg else Var i
  | Abs t ->
      let index = index + 1 in
      Abs (subst ~index ~arg:(shift ~by:1 ~depth:0 ~term:arg) ~term:t)
  | App (t1, t2) -> App (subst ~index ~arg ~term:t1, subst ~index ~arg ~term:t2)

We're checking if the variable index matches the one we want to replace. When we go under a lambda, we increment the index we're looking for, and shift the argument up by 1 so its free variables still refer to the correct binders.

let rec reduce ~term =
  match term with
  | App (Abs body, arg) ->
      shift ~by:(-1) ~depth:0
        ~term:(subst ~index:0 ~arg:(shift ~by:1 ~depth:0 ~term:arg) ~term:body)
  | App (t1, t2) ->
      let t1' = reduce ~term:t1 in
      if t1 <> t1' then App (t1', t2) else App (t1, reduce ~term:t2)
  | Abs t -> Abs (reduce ~term:t)
  | _ -> term

About the case App (Abs body, arg):

First we shift the argument up by 1: shift ~by:1 ~depth:0 ~term:arg. It is about to place it inside the lambda body, where all free variables are one level deeper

Then substitute it at index 0: subst ~index:0 ~arg:... ~term:body. Index 0 refers to the immediately bound variable.

Then shift down by -1: shift ~by:(-1) ~depth:0. After substitution, we're removing one lambda, so we need to decrease all free variable indices.

The rest is similar to the named version, we're reducing from left to right (normal-order), and reducing inside abstractions.

To fully normalize a term:

let rec normalize ~term =
  let t = reduce ~term in
  if term = t then term else normalize ~term:t

This keeps reducing until the term doesn't change anymore

Testing with Church numerals

Now let's test our interpreter with Church numerals. Two is λf.λx. f (f x), which in De Bruijn notation becomes λ. λ. 1 (1 0):

let two = Abs (Abs (App (Var 1, App (Var 1, Var 0))))

And the successor function λn.λf.λx. f (n f x) becomes λ. λ. λ. 1 (2 1 0):

let succ = Abs (Abs (Abs (App (Var 1, App (App (Var 2, Var 1), Var 0)))))

let () =
  let two = Abs (Abs (App (Var 1, App (Var 1, Var 0)))) in
  let succ = Abs (Abs (Abs (App (Var 1, App (App (Var 2, Var 1), Var 0))))) in
  print_endline (to_string ~term:(normalize ~term:(App (succ, two))))

Output: λ.λ.(1 (1 (1 0)))

This is the Church numeral for 3, which is λf.λx. f (f (f x)). It applies f three times to x