DEV Community: angrykoala

Mindfck Devlog 2: Memory Handling, Variables, and Flow Control in Brainfuck

angrykoala — Sun, 27 Apr 2025 21:16:00 +0000

Originally posted on My Personal Blog

This is a follow-up to Part 1.

In the last post, I covered the basics of how brainfuck works and how certain algorithms can help build a language that compiles to it: mindfck.

This time, I’m tackling one of brainfuck’s biggest pain points: manual pointer management. First, I’ll introduce support for accessing arbitrary memory positions. Then, I’ll build on that to add real variables.

Finally, I’ll cover basic abstractions for control flow, like if and while.

Currently, my tool for generating brainfuck code looks like this:

cmd.Add(20)         // Pointer at 0
cmd.MovePointer(1)  // Pointer at 1
cmd.Add(28)
cmd.AddCell(-1, 1)  // Add byte 0 to 1, using 2 as buffer. Pointer stays at byte 1

It’s a step up from raw brainfuck, but still far from ideal. The programmer has to manually track the pointer position and remember where it ends up after each command. What we really need is a way to access any memory cell directly—without thinking about the pointer at all.

Random Memory Access

There are only two commands to move through memory in brainfuck:

Command	Description
`>`	Increment pointer (move right)
`<`	Decrement pointer (move left)

If we want to move to byte 2, we’d write >>:

0	1	2	3	...
0	0	0	0	...
		^

But that only works if we’re starting from byte 0. If we’re at byte 3, moving to byte 2 is just: <.

A simple solution is to track the pointer at compile time. To do this, we add a new field to CommandHandler to track a phantom pointer:

type CommandHandler struct {
    writer  *writer
    pointer int
}

Then, update the pointer whenever > or < appears in the code:

// Move pointer n positions, left or right
func (c *CommandHandler) MovePointer(pos int) {
    c.pointer += pos
    // ...
}

Now, we can compute the movement to any position based on the current "fake" pointer. For example:

>> sets the pointer to 2:

0 1 2 3 ...

0 0 0 0 ...

^
To go to byte 1, just calculate 1 - 2 = -1 → move one step left (<):

0 1 2 3 ...

0 0 0 0 ...

^

Updating Commands

So far, all commands have acting over the pointer’s current position:

MoveByte(3) // Move selected byte, 3 spaces to the right

A more intuitive interface would look like this:

MoveByte(2, 5) // Move byte at position 2 to position 5

To support this, we update all relevant commands to use absolute positions instead of relative ones:

func (c *CommandHandler) Reset(position int)
func (c *CommandHandler) MoveByte(from int, to int)
func (c *CommandHandler) Copy(from int, to int, buffer int)

Then we update the internal pointer movement logic to compute the offset from the current position and apply the difference:

func (c *CommandHandler) movePointer(to int) {
    diff := to - c.pointer
    c.pointer += diff

    if diff > 0 {
        for i := 0; i < diff; i++ {
            c.writer.Command(BFIncPointer)
        }
    }

    if diff < 0 {
        for i := 0; i > diff; i-- {
            c.writer.Command(BFDecPointer)
        }
    }
}

We've renamed MovePointer to movePointer to make it private. Since commands now handle pointer movement internally, exposing MovePointer is no longer necessary, which simplifies the interface.

With these changes, the code becomes much clearer:

cmd.Add(0, 20)          // Add 20 to byte 0
cmd.Add(1, 28)          // Add 28 to byte 1
cmd.AddCell(0, 1, 2)    // Add byte 0 to 1, using 2 as buffer

Now, we don’t need to think about pointer movement at all! And we can even use Go variables for cleaner, more flexible code:

a := 0
b := 1
buffer := 2

cmd.Add(a, 20)
cmd.Add(b, 28)
cmd.AddCell(a, b, buffer)

Reserved Memory Space

You may have noticed that while commands like Reset, Add, or Move have a clean, simple API, others—like AddCell, Copy, or any command that requires extra memory—are trickier to use. The solution? Reserve a few bytes up front for internal use:

const (
    TEMP0 = 0
    TEMP1 = 1
    TEMP2 = 2
    NIL   = 6 // Always 0
    MAIN  = 7 // Beginning of user memory
)

With this setup, Copy can now offer a much cleaner interface:

func (c *CommandHandler) Copy(from int, to int) {
    if from == TEMP0 || to == TEMP0 {
        panic("Invalid COPY, trying to use copy register")
    }
    // Reset TEMP0 and destination
    c.Reset(TEMP0)
    c.Reset(to)

    // Move from → to and TEMP0
    c.movePointer(from)
    c.writer.Command(BFLoopBegin)
    c.Add(to, 1)
    c.Add(TEMP0, 1)
    c.Add(from, -1)
    c.writer.Command(BFLoopEnd)

    c.Move(TEMP0, from)
}

The only caveat is that users must avoid overwriting the reserved memory:

a := cmd.MAIN + 0
b := cmd.MAIN + 1

cmd.Add(a, 20)     // Add 20 to byte "0"
cmd.Add(b, 28)     // Add 28 to byte "1"
cmd.AddCell(a, b)  // No need to pass buffer explicitly

Fixing Loops and Adding `while`

Before we go further, we need to address the elephant in the room: tracking the pointer at compile time just doesn’t work.

Consider this example:

>>>+<+

Our phantom pointer would calculate the final position as 2: three steps right (>>>), then one step left (<). And in this case, it’s correct!

But now let’s throw loops into the mix. Here’s a loop from Part 1:

>>+<+<+[+>]

The first part, >>+<+<+, is fine. Our phantom pointer calculates 2 − 2 = 0, which is correct:

0	1	2	3	...
1	1	1	0	...
^

The second part, however, is a loop: [+>]. Our compiler sees the > and thinks the pointer ends up at position 1. But in reality, since the loop advances the pointer during each iteration, the final position is further to the right.

If we run this code, here’s what actually happens:

0	1	2	3	...
2	2	2	0	...
			^

The final pointer is at position 3!

Reminder: [+>] increments each non-zero cell until it reaches a zero.

This is an unsolvable problem because memory state can depend on user input—thanks to the , command. Even if we tried to run the code ahead of time to determine the real pointer position, the result could still vary across runs.

For a while, I thought this was the end of the road for the project. But then I went back to review the algorithms I had already implemented and noticed something interesting: they all worked fine with the fake pointer, even the ones that used loops!

Let’s take a look at the copy byte algorithm:

[>>+<+<-]>[<+>-]

According to the phantom pointer, the final position should be 1 (>>>> minus <<<).

Let’s walk through the execution:

First loop: >>+<+<- The pointer starts at 0 and ends each iteration back at 0.
> moves the pointer to 1.
Second loop: <+>- Starts at 1 and finishes at 1 after each iteration.

So, the final pointer position is 1, just as expected.

All these algorithms have loops that begin and end in the same position. This makes sense: loops typically rely on the same byte to determine whether to continue or exit. That means the pointer always returns to its starting position, no matter how many times the loop runs.

[>>+<+<-]>[<+>-]
^       ^ ^    ^
0       0 1    1

This means that, as long as a loop starts and finishes on the same byte, we’re safe. This principle even holds with nested loops:

[>>+<+[>>>+<<<]<]>[<+>-]
^     ^   ^   ^ ^ ^    ^
0     1   4   1 0 1    1

I considered different ways to validate this behavior when users write their own code. But then I remembered that this is my language, and I can enforce whatever rules I want:

// Loops, ensuring that the loop begins and ends in the same cell
func (c *CommandHandler) While(condition int, code func()) {
    c.movePointer(condition)
    c.beginLoop()
    code()
    c.goTo(condition)
    c.endLoop()
}

This while implementation takes two parameters: a condition cell to check whether the loop should continue, and a callback containing the loop body.

It moves to the condition cell and starts the loop.
It runs the user-defined commands inside the code callback.
Before ending the loop, it moves back to the condition cell.

Its simplicity might be surprising. But since the loop body runs starting from the condition byte, we can still rely on the phantom pointer and use all existing commands safely inside the loop.

Here’s an example using this while:

cmd := bfwriter.NewCommandHandler()

// Adds 65 ('A') to byte 0
cmd.Add(0, 65)

// Adds 10 to byte 1
cmd.Add(1, 10)

cmd.While(1, func() { // While byte 1 is > 0
    cmd.Print(0)   // Print byte 0
    cmd.Add(0, 1)  // Add 1 to byte 0
    cmd.Add(1, -1) // Subtract 1 from byte 1
})

The output:

ABCDEFGHIJ

Conditionals: `if`

Brainfuck doesn’t support conditionals directly, but we can simulate an if by using a loop that runs only once:

func (c *CommandHandler) If(cond int, code func()) {
    c.Copy(cond, TEMP1)
    c.While(TEMP1, func() {
        code()
        c.Reset(TEMP1)
    })
}

Here’s how it works:

We copy the condition byte. Since we’ll modify it, we don’t want to affect the original.
- We use TEMP1 to avoid interfering with TEMP0 used in Copy.
We use While with TEMP1 as the condition.
Inside the loop, we run the code and then reset TEMP1, ensuring the loop runs only once.

Variables

Using raw memory positions is a big step up from brainfuck, but it’s still far from ideal as memory must be managed manually. The solution? Add support for variables.

Environment¹

The core idea behind variables is to map unique identifiers to memory positions. For that, I use an Env struct to manage this mapping, along with a few helper methods to reserve and access memory²:

type MindfuckEnv struct {
    variables map[string]int // Labels to position mapping
}

func (env *MindfuckEnv) ReserveMemory(label string) string
func (env *MindfuckEnv) ReleaseMemory(label string)
func (env *MindfuckEnv) GetPosition(label string) int

A simple way to assign new positions is to increment from the last used slot³, which avoids memory collisions. But this naive approach has a downside: memory consumption quickly grows, especially with short-lived temporary variables, since memory isn't reused.

To fix this, I introduced ReleaseMemory, and updated the struct to support a smarter allocation strategy:

type MindfuckEnv struct {
    variables      map[string]int    // Labels to position mapping
    reservedMemory common.ItemSet    // Positions currently in use
    freedMemory    []int             // Positions that have been freed
}

Now, we keep track of used and freed memory slots⁴. When allocating new variables, we reuse freed slots first before reserving fresh positions.

A few simple updates to CommandHandler make working with variables much smoother:

Expose ReserveMemory using a new Declare method:

func (c *CommandHandler) Declare(label string) string {
    return c.env.ReserveMemory(label)
}

Update all commands to use variable names instead of raw positions, and manage temp memory internally:

func (c *CommandHandler) Copy(from string, to string) {
    temp0 := c.env.ReserveMemory("_temp0") // Declare temporal variable
    temp1 := c.env.ReserveMemory("_temp1")
    defer c.env.ReleaseMemory(temp0) // Release temporal variable
    defer c.env.ReleaseMemory(temp1)

    // Reset temp and to
    c.Reset(temp0)
    c.Reset(to)

    c.Loop(from, func() {
        c.Inc(to)
        c.Inc(temp0)
        c.Dec(from)
    })

    c.Move(temp0, from)
}

For those unfamiliar with Go: defer delays execution until the surrounding function returns. It's a clean way to handle cleanup like releasing memory, without needing to explicitly call ReleaseMemory at the end.

Thanks to these changes, our pseudo-language now reads much more clearly:

cmd := codegen.New()

var1 := cmd.Declare("var1")
var2 := cmd.Declare("var2")
var3 := cmd.Declare("var3")

cmd.Set(var1, 65)
cmd.Set(var2, 3)

cmd.Add(var1, var2, var3)
cmd.Out(var3)
cmd.Print()

Improving Variables

I was happy with how variables were working—so much so that I started working on the language parser (spoilers for Part 3!). But there was still one small issue bothering me.

Internally, I was declaring variables using reserved labels like:

temp0 := c.env.ReserveMemory("_temp0")

This meant users couldn’t declare variables with names like _temp0, and worse, my own commands had to be careful to avoid naming collisions, just like with the reserved memory positions.

Luckily, I had run into a similar problem before in an unrelated project⁵, so this time I wasn’t going in completely blind.

My solution was to define a Variable interface to represent both named and anonymous variables. This way, every variable tracks its position, and optionally, a label:

type Variable interface {
    Position() int
    hasLabel() bool
    label() string
}

Then I created two implementations of this interface:

NamedVariable: Holds both a memory position and a label.
AnonVariable: Holds only the position, with no label.

Now env.go can simply work with variables and support declaring them with or without a label:

type MindfuckEnv struct {
    labels         map[string]Variable
    reservedMemory utils.ItemSet
    freedMemory    []int
}

func (env *MindfuckEnv) DeclareVariable(label string) Variable
func (env *MindfuckEnv) DeclareAnonVariable() Variable
func (env *MindfuckEnv) ReleaseVariable(v Variable)
func (env *MindfuckEnv) ResolveLabel(label string) Variable

Next came a trivial refactor to use anonymous variables internally:

func (c *CommandHandler) Declare(label string) env.Variable {
    return c.env.DeclareVariable(label)
}

func (c *CommandHandler) Copy(from env.Variable, to env.Variable) {
    temp0 := c.env.DeclareAnonVariable()
    temp1 := c.env.DeclareAnonVariable()
    defer c.env.ReleaseVariable(temp0)
    defer c.env.ReleaseVariable(temp1)

    // Reset temp and to
    c.Reset(temp0)
    c.Reset(to)

    c.Loop(from, func() {
        c.Inc(to)
        c.Inc(temp0)
        c.Dec(from)
    })

    c.Move(temp0, from)
}

Note that only named variables are exposed via Declare. Anonymous variables are reserved for internal use, preventing naming collisions and keeping user's code clean.

Conclusion

After this deep dive into memory handling, we now have the following API:

func Declare(label string) Variable              // Declares a new variable
func Reset(v Variable)                           // Resets v to 0
func Add(v Variable, i int)                      // Increments (or decrements) value i to v
func Set(v Variable, i int)                      // Sets v to given value, same as Reset + Add
func Print(v Variable)                           // Prints v
func Move(from Variable, to Variable)            // Moves from → to
func Copy(from Variable, to Variable)            // Copies from → to
func AddCell(from Variable, target Variable)     // Adds value of from to target
func While(cond Variable, code func())           // While loop
func If(cond Variable, code func())              // If conditional

That’s a solid set of easy-to-use tools for a Go-based abstraction over brainfuck.

In the next part, I’ll cover how I built a simple AST and parser using antlr4⁶ to tie everything together into a real programming language.

Robert Nystrom - Crafting Interpreters. ↩
You can find the full env.go code at this point on GitHub. ↩
This seems to be the approach taken by Headache, another language that transpiles to Brainfuck. ↩
common.ItemSet is just a thin wrapper over Go's map[int]bool, which is the canonical way to implement sets in Go. After reviewing this code, I realized this was entirely unnecessary. A simple counter for the highest reserved position and tracking freedMemory would have been enough. ↩
Cypher Builder, a tool for code generation that also uses the concept of variables. ↩
Antlr Official Website ↩

Mindfck Devlog 1: Making a High Level Programming Language to Brainfuck

angrykoala — Thu, 13 Mar 2025 19:41:00 +0000

Originally posted on My Personal Blog
Part 2

A few months ago, I embarked on another esolang project: Minfck. It's a simple, easy-to-use language that transpiles to the infamous brainfuck¹. In this and following posts, I'll document the journey of making this ridiculous project, along with its challenges and solutions.

With Mindfck, a fairly innocuous piece of code like:

int a
int b
a = 3 + a
a = 33 + a
a = a + 2
int c
a = a + 21
a = a + 2
b = 10 + a
c = a + b
print c

Transpiles to:

>>>>[-]>[-]+++>>>[-]<<[-]<<[>>+>>+<<<<-][-]>>>>[<<<<+>>>>-][-]<[-]<<[>>+>+<<<-][-]>>>[<<<+>>>-][-]<<<<<<<<[>>>>>>>>+<<+<<<<<<-][-]>>>>>>>>[<<<<<<<<+>>>>>>>>-]>[-]<[-]<<<<<<<[>>>>>>>+>+<<<<<<<<-][-]>>>>>>>>[<<<<<<<<+>>>>>>>>-]<[<+>>[-]+>>[-]<[-]<<<[>>>+>+<<<<-][-]>>>>[<<<<+>>>>-]<[<->[-]]>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<+>>>>[-]]<<-]<<<<[-]<<<<[-]>>>>>>[<<<<<<+>>>>+>>-][-]<<[>>+<<-][-]<<<[-]>>>>>>[<<<<<<+>>>+>>>-][-]<<<[>>>+<<<-][-]>[-]+++++++++++++++++++++++++++++++++>>>[-]<<[-]<<[>>+>>+<<<<-][-]>>>>[<<<<+>>>>-][-]<[-]<<[>>+>+<<<-][-]>>>[<<<+>>>-][-]<<<<<<<<[>>>>>>>>+<<+<<<<<<-][-]>>>>>>>>[<<<<<<<<+>>>>>>>>-]>[-]<[-]<<<<<<<[>>>>>>>+>+<<<<<<<<-][-]>>>>>>>>[<<<<<<<<+>>>>>>>>-]<[<+>>[-]+>>[-]<[-]<<<[>>>+>+<<<<-][-]>>>>[<<<<+>>>>-]<[<->[-]]>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<+>>>>[-]]<<-]<<<<[-]<<<<[-]>>>>>>[<<<<<<+>>>>+>>-][-]<<[>>+<<-][-]<<<[-]>>>>>>[<<<<<<+>>>+>>>-][-]<<<[>>>+<<<-][-]>[-]++>>>[-]<<[-]<<<<<<[>>>>>>+>>+<<<<<<<<-][-]>>>>>>>>[<<<<<<<<+>>>>>>>>-][-]<[-]<<<<<<[>>>>>>+>+<<<<<<<-][-]>>>>>>>[<<<<<<<+>>>>>>>-][-]<<<<[>>>>+<<+<<-][-]>>>>[<<<<+>>>>-]>[-]<[-]<<<[>>>+>+<<<<-][-]>>>>[<<<<+>>>>-]<[<+>>[-]+>>[-]<[-]<<<[>>>+>+<<<<-][-]>>>>[<<<<+>>>>-]<[<->[-]]>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<+>>>>[-]]<<-]<<<<[-]<<<<[-]>>>>>>[<<<<<<+>>>>+>>-][-]<<[>>+<<-][-]<<<[-]>>>>>>[<<<<<<+>>>+>>>-][-]<<<[>>>+<<<-]>>[-]>[-]+++++++++++++++++++++>>>[-]<<[-]<<<<<<<<[>>>>>>>>+>>+<<<<<<<<<<-][-]>>>>>>>>>>[<<<<<<<<<<+>>>>>>>>>>-][-]<[-]<<<<<<<<[>>>>>>>>+>+<<<<<<<<<-][-]>>>>>>>>>[<<<<<<<<<+>>>>>>>>>-][-]<<<<[>>>>+<<+<<-][-]>>>>[<<<<+>>>>-]>[-]<[-]<<<[>>>+>+<<<<-][-]>>>>[<<<<+>>>>-]<[<+>>[-]+>>[-]<[-]<<<[>>>+>+<<<<-][-]>>>>[<<<<+>>>>-]<[<->[-]]>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<+>>>>[-]]<<-]<<<<[-]<<<<<<[-]>>>>>>>>[<<<<<<<<+>>>>>>+>>-][-]<<[>>+<<-][-]<<<<<[-]>>>>>>>>[<<<<<<<<+>>>>>+>>>-][-]<<<[>>>+<<<-][-]>[-]++>>>[-]<<[-]<<<<<<<<[>>>>>>>>+>>+<<<<<<<<<<-][-]>>>>>>>>>>[<<<<<<<<<<+>>>>>>>>>>-][-]<[-]<<<<<<<<[>>>>>>>>+>+<<<<<<<<<-][-]>>>>>>>>>[<<<<<<<<<+>>>>>>>>>-][-]<<<<[>>>>+<<+<<-][-]>>>>[<<<<+>>>>-]>[-]<[-]<<<[>>>+>+<<<<-][-]>>>>[<<<<+>>>>-]<[<+>>[-]+>>[-]<[-]<<<[>>>+>+<<<<-][-]>>>>[<<<<+>>>>-]<[<->[-]]>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<+>>>>[-]]<<-]<<<<[-]<<<<<<[-]>>>>>>>>[<<<<<<<<+>>>>>>+>>-][-]<<[>>+<<-][-]<<<<<[-]>>>>>>>>[<<<<<<<<+>>>>>+>>>-][-]<<<[>>>+<<<-][-]>[-]++++++++++>>>[-]<<[-]<<[>>+>>+<<<<-][-]>>>>[<<<<+>>>>-][-]<[-]<<[>>+>+<<<-][-]>>>[<<<+>>>-][-]<<<<<<<<<<[>>>>>>>>>>+<<+<<<<<<<<-][-]>>>>>>>>>>[<<<<<<<<<<+>>>>>>>>>>-]>[-]<[-]<<<<<<<<<[>>>>>>>>>+>+<<<<<<<<<<-][-]>>>>>>>>>>[<<<<<<<<<<+>>>>>>>>>>-]<[<+>>[-]+>>[-]<[-]<<<[>>>+>+<<<<-][-]>>>>[<<<<+>>>>-]<[<->[-]]>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<+>>>>[-]]<<-]<<<<[-]<<<<[-]>>>>>>[<<<<<<+>>>>+>>-][-]<<[>>+<<-][-]<<<[-]>>>>>>[<<<<<<+>>>+>>>-][-]<<<[>>>+<<<-]>>[-]<<[-]<<<<<<[>>>>>>+>>+<<<<<<<<-][-]>>>>>>>>[<<<<<<<<+>>>>>>>>-][-]<[-]<<<<<<[>>>>>>+>+<<<<<<<-][-]>>>>>>>[<<<<<<<+>>>>>>>-][-]<<<<<<[>>>>>>+<<+<<<<-][-]>>>>>>[<<<<<<+>>>>>>-]>[-]<[-]<<<<<[>>>>>+>+<<<<<<-][-]>>>>>>[<<<<<<+>>>>>>-]<[<+>>[-]+>>[-]<[-]<<<[>>>+>+<<<<-][-]>>>>[<<<<+>>>>-]<[<->[-]]>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<+>>>>[-]]<<-][-]<<<<[-]>>[<<+>>>>+<<-][-]>>[<<+>>-][-]<<<[-]>>[<<+>>>+<-][-]>[<+>-][-]<<[-]<<[>>+>>+<<<<-][-]>>>>[<<<<+>>>>-][-]<[-]<<[>>+>+<<<-][-]>>>[<<<+>>>-]>[-]++++++++++>[-]>[-]>[-]>[-]>[-]<<<<<<[-]>>>>>>>[-]+>>>[-]<[-]<<<<<<<<<<<[>>>>>>>>>>>+>+<<<<<<<<<<<<-][-]>>>>>>>>>>>>[<<<<<<<<<<<<+>>>>>>>>>>>>-]<[<<[-]>>[-]]>[-]<[-]<<<<<<<<<<[>>>>>>>>>>+>+<<<<<<<<<<<-][-]>>>>>>>>>>>[<<<<<<<<<<<+>>>>>>>>>>>-]<[<<[-]>>[-]]<[-]+>>[-]<[-]<<[>>+>+<<<-][-]>>>[<<<+>>>-]<[<->[-]]<[<<<<<<+>>>>>>>>[-]<[-]<<<<<<<[>>>>>>>+>+<<<<<<<<-][-]>>>>>>>>[<<<<<<<<+>>>>>>>>-][-]<<<<<<<<<[>>>>>>>>>+<-<<<<<<<<-][-]>>>>>>>>>[<<<<<<<<<+>>>>>>>>>-]<<<<<<<<<<[-]+>>>>>>>>>>>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<<<<<<<[-]>>>>>>>>>>[-]]<[-]<<<<<<<<<[>>>>>>>>>+>+<<<<<<<<<<-][-]>>>>>>>>>>[<<<<<<<<<<+>>>>>>>>>>-]<[<<<<<<<[-]>+>>>>>>>>[-]<[-]<<<<<<<[>>>>>>>+>+<<<<<<<<-][-]>>>>>>>>[<<<<<<<<+>>>>>>>>-][-]<<<<<<<<<<[>>>>>>>>>>+<-<<<<<<<<<-][-]>>>>>>>>>>[<<<<<<<<<<+>>>>>>>>>>-]<<<<<<<<<<<[-]+>>>>>>>>>>>>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<<<<<<<<[-]>>>>>>>>>>>[-]]<[-]<<<<<<<<<<[>>>>>>>>>>+>+<<<<<<<<<<<-][-]>>>>>>>>>>>[<<<<<<<<<<<+>>>>>>>>>>>-]<[<<<<<<<[-]>+>>>>>>>>[-]<[-]<<<<<<<[>>>>>>>+>+<<<<<<<<-][-]>>>>>>>>[<<<<<<<<+>>>>>>>>-][-]<<<<<<<<<<<[>>>>>>>>>>>+<-<<<<<<<<<<-][-]>>>>>>>>>>>[<<<<<<<<<<<+>>>>>>>>>>>-]<<<<<<<<<<<<[-]+>>>>>>>>>>>>>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<<<<<<<<<[-]>>>>>>>>>>>>[-]]<[-]<<<<<<<<<<<[>>>>>>>>>>>+>+<<<<<<<<<<<<-][-]>>>>>>>>>>>>[<<<<<<<<<<<<+>>>>>>>>>>>>-]<[<<<<<<<[-]>+>>>>>>>>[-]<[-]<<<<<<<[>>>>>>>+>+<<<<<<<<-][-]>>>>>>>>[<<<<<<<<+>>>>>>>>-][-]<<<<<<<<<<<<[>>>>>>>>>>>>+<-<<<<<<<<<<<-][-]>>>>>>>>>>>>[<<<<<<<<<<<<+>>>>>>>>>>>>-]<<<<<<<<<<<<<[-]+>>>>>>>>>>>>>>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<<<<<<<<<<[-]>>>>>>>>>>>>>[-]]<[-]<<<<<<<<<<<<[>>>>>>>>>>>>+>+<<<<<<<<<<<<<-][-]>>>>>>>>>>>>>[<<<<<<<<<<<<<+>>>>>>>>>>>>>-]<[<<<<<<<[-]>+>>>>>>>>[-]<[-]<<<<<<<[>>>>>>>+>+<<<<<<<<-][-]>>>>>>>>[<<<<<<<<+>>>>>>>>-][-]<<<<<<<<<<<<<[>>>>>>>>>>>>>+<-<<<<<<<<<<<<-][-]>>>>>>>>>>>>>[<<<<<<<<<<<<<+>>>>>>>>>>>>>-]<<<<<<<<<<<<<<[-]+>>>>>>>>>>>>>>>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<<<<<<<<<<<[-]>>>>>>>>>>>>>>[-]]<<[-]]<[-]]<[-]]<[-]]+>>[-]<[-]<<<<<<<<<<<[>>>>>>>>>>>+>+<<<<<<<<<<<<-][-]>>>>>>>>>>>>[<<<<<<<<<<<<+>>>>>>>>>>>>-]<[<->[-]]>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<<<<<<<<<->>>>>>>>>>>>[-]]<<<<<<<<<<<->>>>>>>>[-]+>>>[-]<[-]<<<<<<<<<<<[>>>>>>>>>>>+>+<<<<<<<<<<<<-][-]>>>>>>>>>>>>[<<<<<<<<<<<<+>>>>>>>>>>>>-]<[<<[-]>>[-]]>[-]<[-]<<<<<<<<<<[>>>>>>>>>>+>+<<<<<<<<<<<-][-]>>>>>>>>>>>[<<<<<<<<<<<+>>>>>>>>>>>-]<[<<[-]>>[-]]<[-]+>>[-]<[-]<<[>>+>+<<<-][-]>>>[<<<+>>>-]<[<->[-]]<]<[-]++++++++++++++++++++++++++++++++++++++++++++++++>>[-]<[-]<<[>>+>+<<<-][-]>>>[<<<+>>>-]<[>[-]<<[>>+<<<+>-][-]>>[<<+>>-]<<<.>>[-]]+++>[-]+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>[-]>>>>>[-]<<[-]<<<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>>>+>>+<<<<<<<<<<<<<<<<<<<-][-]>>>>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>-][-]<[-]<<<<<<[>>>>>>+>+<<<<<<<-][-]>>>>>>>[<<<<<<<+>>>>>>>-]<<<<[-]>[-]<<[-]>>>[<<+>>>[-<<<[-]>+>>]<<<[-<+>]>[->>+<<]>>-<-]<[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<<<<<<<<[-]+>>>>>>>>>>>[-]]>[-]<[-]<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>+>+<<<<<<<<<<<<<<<<-][-]>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>-][-]<<<<[>>>>+<-<<<-][-]>>>>[<<<<+>>>>-]<<[-]+>>>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<[-]>>[-]]<[-]<[>+>+<<-][-]>>[<<+>>-]<[>>>>>[-]<<[-]<<<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>>>+>>+<<<<<<<<<<<<<<<<<<<-][-]>>>>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>-][-]<[-]<<<<<<[>>>>>>+>+<<<<<<<-][-]>>>>>>>[<<<<<<<+>>>>>>>-]<<<<[-]>[-]<<<<<<<<<<<<<[-]>>>>>>>>>>>>>>[<<+>>>[-<<<[-]>+>>]<<<[-<<<<<<<<<<<<+>>>>>>>>>>>>]>[->>+<<]>>-<-]<<<[-]]<[-]<<<<<<<<<<[>>>>>>>>>>+>+<<<<<<<<<<<-][-]>>>>>>>>>>>[<<<<<<<<<<<+>>>>>>>>>>>-]<[>[-]<<<<[>>>>+<<<<<<+>>-][-]>>>>[<<<<+>>>>-]<<<<<<.>>>>>[-]]<<[-]>[-]+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>[-]>>>>>[-]<<[-]<<<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>>>+>>+<<<<<<<<<<<<<<<<<<<-][-]>>>>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>-][-]<[-]<<<<<<[>>>>>>+>+<<<<<<<-][-]>>>>>>>[<<<<<<<+>>>>>>>-]<<<<[-]>[-]<<[-]>>>[<<+>>>[-<<<[-]>+>>]<<<[-<+>]>[->>+<<]>>-<-]<[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<<<<<<<<[-]+>>>>>>>>>>>[-]]>[-]<[-]<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>+>+<<<<<<<<<<<<<<<<-][-]>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>-][-]<<<<[>>>>+<-<<<-][-]>>>>[<<<<+>>>>-]<<[-]+>>>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<[-]>>[-]]<[-]<[>+>+<<-][-]>>[<<+>>-]<[>>>>>[-]<<[-]<<<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>>>+>>+<<<<<<<<<<<<<<<<<<<-][-]>>>>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>-][-]<[-]<<<<<<[>>>>>>+>+<<<<<<<-][-]>>>>>>>[<<<<<<<+>>>>>>>-]<<<<[-]>[-]<<<<<<<<<<<<<[-]>>>>>>>>>>>>>>[<<+>>>[-<<<[-]>+>>]<<<[-<<<<<<<<<<<<+>>>>>>>>>>>>]>[->>+<<]>>-<-]<<<[-]]<[-]<<<<<<<<<<[>>>>>>>>>>+>+<<<<<<<<<<<-][-]>>>>>>>>>>>[<<<<<<<<<<<+>>>>>>>>>>>-]<[>[-]<<<<[>>>>+<<<<<<<+>>>-][-]>>>>[<<<<+>>>>-]<<<<<<<.>>>>>>[-]]<<[-]>[-]+++++++++>[-]>>>>>[-]<<[-]<<<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>>>+>>+<<<<<<<<<<<<<<<<<<<-][-]>>>>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>-][-]<[-]<<<<<<[>>>>>>+>+<<<<<<<-][-]>>>>>>>[<<<<<<<+>>>>>>>-]<<<<[-]>[-]<<[-]>>>[<<+>>>[-<<<[-]>+>>]<<<[-<+>]>[->>+<<]>>-<-]<[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<<<<<<<<<<[-]+>>>>>>>>>>>[-]]>[-]<[-]<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>+>+<<<<<<<<<<<<<<<<-][-]>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>-][-]<<<<[>>>>+<-<<<-][-]>>>>[<<<<+>>>>-]<<[-]+>>>[-]<[-]<[>+>+<<-][-]>>[<<+>>-]<[<<[-]>>[-]]<[-]<[>+>+<<-][-]>>[<<+>>-]<[>>>>>[-]<<[-]<<<<<<<<<<<<<<<<<[>>>>>>>>>>>>>>>>>+>>+<<<<<<<<<<<<<<<<<<<-][-]>>>>>>>>>>>>>>>>>>>[<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>-][-]<[-]<<<<<<[>>>>>>+>+<<<<<<<-][-]>>>>>>>[<<<<<<<+>>>>>>>-]<<<<[-]>[-]<<<<<<<<<<<<<[-]>>>>>>>>>>>>>>[<<+>>>[-<<<[-]>+>>]<<<[-<<<<<<<<<<<<+>>>>>>>>>>>>]>[->>+<<]>>-<-]<<<[-]]<[-]<<<<<<<<<<[>>>>>>>>>>+>+<<<<<<<<<<<-][-]>>>>>>>>>>>[<<<<<<<<<<<+>>>>>>>>>>>-]<[>[-]<<<<[>>>>+<<<<<<<<+>>>>-][-]>>>>[<<<<+>>>>-]<<<<<<<<.>>>>>>>[-]]<<<[>>>+<<<<<<<<+>>>>>-][-]>>>[<<<+>>>-]<<<<<<<<.

Building a high-level, usable language that transpiles to brainfuck is a useless project on its own; it is great, however, for learning language design and creating tools to handle less-than-ideal environments. I believe the approach I've taken to make this possible may be useful for solving real-world problems.

Let's Talk About Brainfuck

Brainfuck is an (in)famously difficult language to program with; however, it is surprisingly easy to learn. Luckily, you don't have to become an expert, I certainly didn't!

Brainfuck Primer

In a nutshell, a brainfuck program works with a list of bytes and a single pointer, pointing at the first byte:

0	1	2	3	...
0	0	0	0	...
^

Note that all bytes are initialized to 0. In memory diagrams, I've numbered the bytes to better visualize what is happening. These indexes are irrelevant to brainfuck.

Brainfuck code is composed of 8 instructions². Each one is represented with a single character. Any other character is ignored and is considered a comment.Here is a cheatsheet:

Command	Description
`>`	Increment pointer (move right)
`<`	Decrement pointer (move left)
`+`	Increment byte by 1
`-`	Decrement byte by 1
`.`	Print byte as an ascii character
`,`	Reads an ASCII character byte
`[`	Begin Loop: if byte is zero, jump to matching `]`
`]`	End Loop: If byte is nonzero, jump to matching `[`

All commands target the current byte of the pointer.

For example, the following program:

>++>++ This comment is ignored

Finishes with the memory ain the following state:

0	1	2	3	...
0	2	2	0	...
		^

With . and ,, we can write or read a byte into and from memory (as ASCII characters):

,+.

input

output

A more complex example using loops:

>>+<+<+[+>]

The first part of the code, >>+<+<+, initializes the memory as follows:

0	1	2	3	...
1	1	1	0	...
^

The loop [+>] will increment 1 and move right until the selected byte is 0. In this case it will add 1 to all non-zero values until it reaches 0:

0	1	2	3	...
2	2	2	0	...
			^

Note that infinite loops are easy to come by in brainfuck. Changing the example above to [>+] causes the program to run indefinitely because it increments the current byte before the loops end

You can try playing around with brainfuck using any online interpreter³.

Making a Brainfuck Interpreter in Go

Implementing an interpreter for brainfuck is trivial and can be done in a couple of hours. A while ago, I had to learn Go⁴. As a learning exercise, I decided to write a brainfuck interpreter, which soon devolved into the madness that is Mindfck.

We start with a simple data structure to hold the memory as an array, a pointer and an output buffer:

package bfinterpreter

import "fmt"

type Interpreter struct {
    Memory []byte
    memPtr int
    Output []byte
}

For those unfamiliar with Go⁴, Go uses struct instead of classes. Uppercase properties and methods are public; lowercase are only accessible within the same package.

Running the interpreter is as simple as reading characters and executing operations in a switch statement, updating the structure:

// ...

func (interpreter *Interpreter) Run(code string) {
    for i := 0; i < len(code); i++ {
            switch code[i] {
            case '+':
                interpreter.Memory[interpreter.memPtr] += 1
            case '-':
                interpreter.Memory[interpreter.memPtr] -= 1
            case '>':
                interpreter.memPtr += 1
                if len(interpreter.Memory) <= interpreter.memPtr {
                    // Increase memory array as needed
                    interpreter.Memory = append(interpreter.Memory, 0)
                }
            case '<':
                interpreter.memPtr -= 1
                if interpreter.memPtr < 0 {
                    panic("Kaboom")
                }
            // Other instructions
        }
    }
}

You can find the full code on GitHub.

There are a few conventions worth mentioning:

The memory size is not specified in this implementation; other implementations may impose a strict limit.
This implementation supports "byte wrapping". If a byte overflows (> 255), it wraps to 0. If it underflows (< 0), it also wraps to 0.
This implementation does not support "memory wrapping". If the pointer underflows (< 0), it will panic.

Different interpreters may have slightly different conventions⁵, which some programs may rely on.

The code in this project will not rely on either byte or memory wrapping⁶. This ensures that code generated with Mindfck can be run directly on most common brainfuck interpreters.

Custom Debugger

One advantage of building your own interpreter is that you can add any tooling you need. In this case, I added an extra command, #, to print debugging information:

func (interpreter *Interpreter) Run(code string) {
    // ...
        case '#':
            interpreter.Debug()
    // ...
}

func (interpreter *Interpreter) Debug() {
    fmt.Println("Memory:", interpreter.Memory)
    fmt.Println("Output:", interpreter.Output)
    fmt.Println("Pointer:", interpreter.memPtr)
}

By design, brainfuck ignores any invalid command, treating them as comments. This means code written with this extra debugging command will simply be ignored by other interpreters⁷.

Basic Algorithms

Before embarking on creating a full-featured language, I had to learn a bit more about brainfuck. My knowledge of the language before this project was pitiful—aside from making some interpreters. So my first step was to learn some basic algorithms⁸.

Reset Byte

Arguably, the most basic algorithm with some utility is resetting a byte:

[-]

This algorithm loops while decrementing the current byte until it reaches zero, at which point it exits the loop. This is particularly useful because brainfuck doesn't have a built-in way to set bytes to a specific value (except when using input: ,). Instead, values must be adjusted incrementally using + or -. Being able to reset a byte is essential for reusing memory.

For example, setting a byte to 3, regardless of its previous value:

[-]+++

Move Byte

Moving bytes is the foundation of most other algorithms. In this case, we want to move the value in position 0:

0	1	2	3	...
48	0	0	0	...
^

To position 2:

0	1	2	3	...
0	0	48	0	...
		^

[>>+<<-]

This is done with a single loop. Let's break it down:

The first part, >>+, increments the target byte by one:

0 1 2 3 ...

48 0 1 0 ...

^
The second part, <<-, decrements the source byte by one:

0 1 2 3 ...

47 0 1 0 ...

^
Repeat until the source byte reaches 0.

0	1	2	3	...
48	0	1	0	...
		^

0	1	2	3	...
47	0	1	0	...
^

When the loop finishes, the target byte contains the same value the source byte had at the beginning:

0	1	2	3	...
0	0	48	0	...
^

Note that this loop must end with the pointer on the source byte during each iteration, as this byte acts as a counter.

This algorithm assumes the target byte starts at 0. What if it doesn’t? We can reset it first:

>>[-] Reset byte 2
<< Go to byte 0
[>>+<<-] Move byte 0 to byte 2

Remember, brainfuck ignores all invalid characters, so the previous snippet is valid brainfuck that you can copy and paste.

Copy Byte

What if, instead of moving the byte, we want to make a full copy of it? To do this, we need to use a third byte as a buffer:

[>>+<+<-]>[<+>-]

Okay, it’s starting to get a bit tricky, but bear with me:

This algorithm consists of 2 loops. The first loop [>>+<+<-] is doing something very similar to moving a byte, with some extra steps:

>>+ Go to the target byte (2) and increment it:

0 1 2 3 ...

48 0 1 0 ...

^
<+ Go to the buffer byte (1) and increment it:

0 1 2 3 ...

48 1 1 0 ...

^
<- Go to the source byte and decrement it:

0 1 2 3 ...

47 1 1 0 ...

^
Repeat

0	1	2	3	...
48	0	1	0	...
		^

0	1	2	3	...
48	1	1	0	...
	^

0	1	2	3	...
47	1	1	0	...
^

Once the loop finishes, the memory will look like this:

0	1	2	3	...
0	48	48	0	...
^

We already made a second copy, but it is not in the original position (1)! Luckily, we already know how to move a byte:

> Go to the buffer byte.
[<+>-] Move the buffer byte to the source byte.

This leaves the memory with a copy of byte 0 in byte 2:

0	1	2	3	...
48	0	48	0	...
	^

Add Bytes

One last algorithm for extra points. Let's imagine we want to add 2 bytes (0 and 1):

0	1	2	3	...
10	20	0	0	...
^

So, we end up with a new byte (2):

0	1	2	3	...
10	20	30	0	...
		^

Instead of jumping straight into brainfuck, let's plan how to achieve this using the previous algorithms:

Copy byte 0 into byte 2.
Increment byte 2 by the same value of byte 1.

The first step is now trivial with the Copy Byte algorithm.

For the second step, we can actually use Copy Byte again! Since with Copy Byte we are just increasing the target byte, if the variable is not 0, we will be adding them!

[>>+>+<<<-]>>>[<<<+>>>-] Copy byte 0 to 2, using 3 as buffer
<<[>>+<+<-]>>[<<+>>-] Copy byte 1 to 2, using 3 as buffer

This code may look very different from previous snippets, but if you focus on each component of the loop, you'll see that the only difference is the pointers moving to different bytes⁹.

At this point, the code is getting harder to follow. The takeaway is that we can compose relatively complex code from smaller, easier algorithms, and keep building from these foundations.

The First Abstraction: Code Generation

Armed with some rudimentary brainfuck algorithms, I decided to start implementing a small library. This would help me generate brainfuck code in Go.

Writer

To aid with code generation, I made a simple Writer struct¹⁰. Nothing fancy, as this is my first project in Go:

package bfwriter

import (
    "fmt"
    "strings"
)

type BFCommand string

const (
    BFInc        BFCommand = "+"
    BFDec        BFCommand = "-"
    BFIncPointer BFCommand = ">"
    BFDecPointer BFCommand = "<"
    BFOut        BFCommand = "."
    BFIn         BFCommand = ","
    BFLoopBegin  BFCommand = "["
    BFLoopEnd    BFCommand = "]"
)

type writer struct {
    sb *strings.Builder
}

func NewWriter() *writer {
    var sb strings.Builder
    var wrt writer
    wrt.sb = &sb

    return &wrt
}

// Appends BF command into the strings builder
func (wrt *writer) Command(command BFCommand) {
    wrt.sb.WriteString(string(command))
}

// Adds an arbitrary string as a comment
func (wrt *writer) Comment(comment string) {
    wrt.sb.WriteString("  ")
    wrt.sb.WriteString(comment)
    wrt.sb.WriteString("\n")
}

// Prints the string to stdout
func (wrt *writer) Print() {
    fmt.Println(wrt.sb.String())
}

This way, I don't need to remember how to use strings.Builder.

CommandHandler

All the commands and utilities will be in the CommandHandler struct¹¹:

type CommandHandler struct {
    writer *writer
}

func NewCommandHandler() *CommandHandler {
    cmd := CommandHandler{
        writer: NewWriter(),
    }

    return &cmd
}

// Move pointer n positions, left or right
// MovePointer(3)     ">>>"
// MovePointer(-3)    "<<<"
// MovePointer(-2+1)  "<"
func (c *CommandHandler) MovePointer(pos int) {
    if pos > 0 {
        for i := 0; i < pos; i++ {
            c.writer.Command(BFIncPointer)
        }
    }

    if pos < 0 {
        for i := 0; i > pos; i-- {
            c.writer.Command(BFDecPointer)
        }
    }
}

// Add (or subtract) a certain number to the current cell
// Add(3)    "+++"
func (c *CommandHandler) Add(count int) {
    if count > 0 {
        for i := 0; i < count; i++ {
            c.writer.Command(BFInc)
        }
    }

    if count < 0 {
        for i := 0; i > count; i-- {
            c.writer.Command(BFDec)
        }
    }
}

// Resets cell to 0 ([-])
func (c *CommandHandler) Reset() {
    c.writer.Command(BFLoopBegin)
    c.Add(-1) // Subtracts 1
    c.writer.Command(BFLoopEnd)
}

// Move the value of current byte to target byte
// (counting from current byte)
func (c *CommandHandler) MoveByte(to int) {
    c.writer.Command(BFLoopBegin)
    c.MovePointer(to) // Go to target byte
    c.Add(1)
    c.MovePointer(-to) // Returns to source
    c.Add(-1)
    c.writer.Command(BFLoopEnd)
}

// Copy current byte to target byte, using temp as buffer
func (c *CommandHandler) Copy(to int, temp int) {
    // Implementation is similar to MoveByte,
    // a direct translation from brainfuck
}

Just by having some basic commands and helpers, we can compose more complex algorithms like addition with very little actual brainfuck going into their implementations:

// Adds byte y to current byte, using temp,
// modifies current byte
func (c *CommandHandler) AddCell(y int, temp int) {
    c.MovePointer(y)
    c.Copy(-y, -y+temp) // Copy y into source, pass the relative position of temp to y
    c.MovePointer(-y)   // Return to source
}

Using this helper class, we can start building some (very) basic programs:

cmd := bfwriter.NewCommandHandler()

// Adds 20 to byte 0
cmd.Add(20)
// Move to the right (byte 1)
cmd.MovePointer(1)
// Adds 28 to byte 1
cmd.Add(28)
// Adds byte on the left (byte 0) to current byte (1),
// uses byte to the right (3) as a temp variable
cmd.AddCell(-1, 1)

The generated brainfuck:

++++++++++++++++++++>++++++++++++++++++++++++++++<>>[-]<<[>+>+<<-]>>[<<+>>-]<<>

The resulting memory state:

0	1	2	3	...
20	48	0	0	...
	^

This is starting to look like a useful tool to generate brainfuck code. This is still far from the promised language. At the moment, any code using these commands requires manually handling the pointer, which is prone to errors and one of the hardest parts of programming brainfuck.

Conclusion

In this post, I've covered the basic foundations of brainfuck that we will need to create a usable high-level language targeting brainfuck. In the next devlog, I'll cover how to improve memory access, so we don't need to deal with relative pointers anymore in our language. Eventually, we will be able to ignore the pointer altogether!

Wikipedia - Brainfuck ↩
Wikipedia - Brainfuck Language Design ↩
Nayuki Brainfuck Interpreter ↩
The Go Programming Language ↩
esolangs.org - Brainfuck Conventions ↩
It won't, however, consider the memory limitations of some implementations. ↩
Using # as a debugging breakpoint is not unique to this interpreter, kvbc's Brainfuck IDE provides a similar feature. ↩
An invaluable source of brainfuck algorithms is esolangs.org - Brainfuck Algorithms ↩
For those really serious about learning brainfuck. esolangs.org uses a shortened notation to make it easier to read brainfuck algorithms in which the target bytes are written instead of the actual pointer movements. For example adding 2 bytes looks like: [c+d+a-]d[a+d-]b[c+d+b-]d[b+d-] ↩
writer.go in GitHub ↩
commands.go in Github ↩

I needed browser automation for testing, so I obviously wrote my own tool

angrykoala — Fri, 22 Mar 2019 19:33:14 +0000

Around a year ago, I decided to start using a browser automation tool to write some tests for my project front-end. While some degree of testing could be achieved by writing unit tests, mocks and jsdom, in the end, these tests couldn't reflect real interactions and properly detect errors.

Because these tests were going to be written by me and other developers (no QA team available!). I needed the tests to be as simple to write and maintain as possible to avoid wasting too much dev time and (more importantly) to avoid devs (and myself) stop writing tests due to laziness.

With this in mind I started searching for the correct browser automation tool for my case, with my priority being simplicity to write tests. During this process I tried several tools, in some cases using them for weeks:

Selenium
Zombie.js - deprecated
Phantomjs - deprecated
Nightmare.js - not actively maintained
Puppeteer

All of these tools (and other I've been trying since) where, for me, either too difficult to setup, had little support for writing tests or relied in external (and usually paid) services.

So, as any sane developer would do, I decided to build my own tools. Of course, I wasn't going to build a headless browser from scratch, after testing a few of the above mentioned, I decided to go with Puppeteer as a base for my own tool. It was reliable, powerful, easy to setup and well-maintained. And so, I started building wendigo, a full wrapper on top of Puppeteer to make testing easier and add features as I needed.

After a few weeks of development in my free time, the efforts started to pay off. Integration and E2E tests started to look cleaner on several projects at my company. Adding built-in assertion methods greatly simplified tests. Going from a test written in Puppeteer like this:

// Test a modal text with Puppeteer
await page.click(".my-btn");
await page.waitForSelector("#my-modal")
const modalText = await page.evaluate(() => {
    const modalElement = document.querySelector("#my-modal");
    return modalElement.textContent;
})
assert.strictEqual(modalText, "Button Clicked");

To this:

// Test a modal text with Wendigo
await browser.click(".my-btn");
await browser.waitFor("#my-modal");
await browser.assert.text("#my-modal", "Button Clicked");

The more complex the test, the bigger was the difference.

After more than a year on development. Wendigo already provides not only simple built-in assertions, but a big set of features:

Easy setup (npm install --save-dev wendigo)
Complex queries such as elementFromPoint(x,y), findByTextContaining(text).
One-line assertions for most common scenarios.
LocalStorage and Cookies interfaces and assertions.
Requests mocks. Allowing to emulate server errors, 3rd party requests, etc.
Plugin system to add extra modules or your own methods as needed.
Agnostic, it works on any Node.js based framework, testing toolchain or in Docker and CI.
Full access to underlying Puppeteer methods.

These have proven to be effective features for fast and reliable testing. Of course, there are some shortcoming on using Wendigo instead of other alternatives:

Only Chrome supported.
The abstraction layers provided by Wendigo may result on unexpected behaviors on some cases.
Node.js required for running and writing tests.

An example of how a test with Wendigo using mocha would look like:


const assert = require('assert');
const Wendigo = require('wendigo');

describe("My Tests", function() {
    this.timeout(5000); // Recommended for CI or slower machines
    let browser;

    beforeEach(async() => {
        browser = await Wendigo.createBrowser();
    });

    afterEach(async() => {
        await browser.close();
    });

    after(async() => {
        // After all tests finished, makes sure all browsers are closed
        await Wendigo.stop(); 
    });

    it("Page Title", async() => {
        await browser.open("http://localhost");
        await browser.assert.text("h1#main-title", "My Webpage");
        await browser.assert.title("My Webpage");
    });

    it("Open Menu", async() => {
        await browser.open("http://localhost");
        await browser.assert.not.visible(".menu");
        await browser.click(".btn.open-menu");
        await browser.assert.visible(".menu");
    });

    it("Initial Request To API Fails Gracefully", async() => {
        browser.requests.mock("http://localhost/api", {
          status: 500
        });
        await browser.open("http://localhost", {
            clearRequestMocks: false // Keeps the mock created before
        });

        // Show red text with error message
        await browser.assert.text(".error-message", "Error loading the API");
        await browser.assert.style(".error-message", "color", "red");
    });
});

This tool is completely open-source on GitHub, tested and documented and still on active development. Currently I'm trying to get feedback on improvements, bugs or features to help other developers with their front-end and E2E testing.

angrykoala / wendigo

A proper monster for front-end automated testing

Wendigo

by @angrykoala

A proper monster for front-end automated testing.

Wendigo (/wɛndɪɡo/) simplify your front-end and end-to-end automated testing using Puppeteer. Install it with npm install --save-dev wendigo.

WARNING: This documentation refers to Wendigo 2, if you are using previous versions of Wendigo, go here.

Consider the following example using just Puppeteer:

await page.click(".my-btn");
await page.waitForSelector("#my-modal")
const modalText = await page.evaluate(() => {
    const modalElement = document.querySelector("#my-modal");
    return modalElement.textContent;
})
assert.strictEqual(modalText, "Button Clicked");

The same test can be written like this with Wendigo:

await browser.click(".my-btn");
await browser.waitFor("#my-modal");
await browser.assert.text("#my-modal", "Button Clicked");

…

View on GitHub

DEV Community: angrykoala

Mindfck Devlog 2: Memory Handling, Variables, and Flow Control in Brainfuck

Random Memory Access

Updating Commands

Reserved Memory Space

Fixing Loops and Adding while

Conditionals: if

Variables

Environment1

Improving Variables

Conclusion

Mindfck Devlog 1: Making a High Level Programming Language to Brainfuck

Let's Talk About Brainfuck

Brainfuck Primer

Making a Brainfuck Interpreter in Go

Custom Debugger

Basic Algorithms

The First Abstraction: Code Generation

Writer

CommandHandler

Conclusion

I needed browser automation for testing, so I obviously wrote my own tool

angrykoala / wendigo

A proper monster for front-end automated testing

Wendigo

Fixing Loops and Adding `while`

Conditionals: `if`

Environment¹