LLMs — they’re everywhere now. If you throw a rock you’ll hit someone talking about how LLMs are great or terrible or saying “ouch!” or saying “someone stop that guy! he just thew a rock at my son!” Apparently the LLMs have gotten good enough to write web applications from scratch, compete in the math olympiad, and find the most highly populated elementary schools for our beautiful warfighters to blow up. If it can do all of this then surely it will automate a midwit like me out of my cushy whitecollar job in no time.

So I ask one simple question — can it frobnicate my memory?

What?

You heard me - can it frobnicate my memory? Can it do that? If I ask it nicely - will it FROB my MEM?

CAN. IT. FROBNICATE. MY. FUCKING. MEMORY.

memfrob

From the manual:

void *memfrob(size_t n; void s[n], size_t n);

The memfrob() function obfuscates the first n bytes of the memory area s by exclusive-ORing each character with the number 42. The effect can be reversed by using memfrob() on the obfuscated memory area.

Note that this function is not a proper encryption routine as the XOR constant is fixed, and is suitable only for hiding strings.

So

So… can the LLM frob my mem? "hi there mr chatbot":

BC
^BOXO
GX
IBK^HE^

Claude

It seems that Mr Claude cannot frob my mem.

He did provide many details of what it means to frob mem, including a nicely formatted table that was only wrong for a few characters, and then provided an answer that was also wrong.

Gemini

It seems that Mr Gemini cannot frob my mem.

Mr Gemini kinda shit himself here. He told me what it means to frobnicate, but then said the characters I gave him are non-printable when frobnicated (not true, see the blob of frob above) and printed a string of completely incorrect garbage. Similar to Mr Claude, he gave me a table, but gave up after 4 characters. I really don’t know what he was smoking when he wrote this. This was by far the worst attempt.

ChatGPT

It seems that Mr ChatGPT can almost frob my mem.

I will say that I asked Mr ChatGPT to frob my mem earlier today, and he was able to do it without issue. But when I came back to try again for this post, he got somewhat confused. \x0A is a hex escape code for newline, but then he switched to the more common \n. Not wrong, but a little weird. But he added in a random space between B and C, which is wrong. Still one of the better showings here.

DeepSeek

It seems that Mr DeepSeek cannot frob my mem, but Dr DeepSeek almost got it after lecturing me.

The “instant” version of DeepSeek got most of it right when it went letter-by-letter, and then gave a result that was also almost what it gave from the letter-by-letter example.

The “expert” version decided to not actually give me an answer, and similar to Mr Gemini, incorrectly stated that the characters would be non-printable. But then she asked me if I wanted her to actually give me an answer. After saying “yes” she went letter-by-letter giving the correct answer, and then threw in a random extra newline in the final summary. So close!

The only reason I tried the fancier version of DeepSeek’s model but not the other companies’ models is that DeepSeek didn’t make me swipe a credit card and put it right next to the “instant” one. I don’t care enough about this stuff to pay for any of these models, and I don’t have the patience to figure out how to get the “best” model that doesn’t involve the company nickel-and-diming me.

Copilot

It seems that Mr Copilot cannot frob my mem.

Similar to Dr DeepSeek, Mr Copilot gave me a lecture instead of an answer, with the option to give me an answer if I consented. I did consent, but unlike Dr DeepSeek, it gave me a garbage answer. Similar to Mr Gemini, it tried to show its work for a couple of steps and gave up. This is the second worst showing after Gemini.

Qwen

It seems that Mr Qwen can frob my mem.

Finally. Someone can frob my mem, with no mistakes, and without some long-winded lecture.

Conculsion

Unfortunately many of the robots do not seem to contain the human emotions necessary to understand frobnication. Perhaps another bajillion dollars worth of training and they will develop souls, and know what it means to be human and to frobnicate one’s memories. Or they could just copy whatever it is that Alibaba is doing, since Qwen seemed to figure it out.

If you try to repeat this, you’ll probably get totally different results. If you want to reliably frobnicate memory, then write a script to do it. Or if you’re a lazy bum, ask the robot to write the script for you. They seem pretty good at that, actually.

There are a bunch of things that I could do here:

• I could have it return an array with a default size, or maybe something like size equal to the absolute value of the number passed in. I don’t like this, since it’s unintuitive and could lead to further errors.
• Return null, a nullable array, or an error type. I don’t like this either - then every time you create an array you need to add null checking and potentially return null.
• I could add unsigned integers to my language and force the array size to be unsigned. This is what rust does. This is not the worst option, but I find unsigned numbers to not be that useful. Most users would probably just cast to unsigned without thinking about it anyway. I also don’t want to allow arrays of size 0, and unsigned integers can still be zero.
• Throw an exception. I don’t like exceptions - but this seems like the correct thing to do. Passing a negative number to an array constructor should be pretty unusual, and I would rather have the flexibility of allowing arrays to be initialized to a dynmaic value. This is what Java does - though strangely only for negative numbers - for some reason it allows zero.

I think I do want to allow some exceptions in my language, but minimize them to the extent that I can. Exceptions are nice for things that happen rarely, but would incur some massive performance hit if you got rid of them, like array indexing or math (division by zero… zero values make life so painful). Also for things like assertions - if someone is using a function / constructor the wrong way, I think an exception will quickly let them know that they’re using it incorrectly, rather than making them propagate the error or by doing something unexpected that doesn’t crash.

I was also thinking about how to implement indexing and wondering about what other languages do, so I took a look to see what Haskell does. Surprisingly most of the functions in Data.List.Index will just return your original list if you give them an invalid index. This is documented, but if I were looking at source code that used these functions, I might not expect it. I think this also might be a case where exceptions make more sense (rust considers this to be the case, anyhow).

I think sum types are a really nice feature. C has had unions for a long time, but doesn’t provide any mechanism for safe usage. You can set something to an int and then read it as a pointer, the main reason for their existence is really just to circumvent the typechecker. As a result, readinf the contents of a union without proper care might give you weird results or crash your program.

The union’s superior cousin, algebraic datatypes (ADTs for short), are a bit nicer. They’ve been around since at least since the days of [the ML programming language](https://en.wikipedia.org/wiki/ML_(programming_language) and been included in subsequent languages of that style of langauge, such as Haskell and OCaml. More recent languages like TypeScript and Rust have popularized this feature in the world of not-functional programming.

I’ve been thinking that I should add something similar to this in del. I think ADTs are a superior way to represent many kinds of data, and pattern matching can be quite a nice feature. One question I still haven’t fully found an answer for is “how much ADT-ness should I add to the language?” Should I have the ability to have null values (and null unsafety) or should ADTs be baked into the type system deeply enough that these kinds of errors can’t exist? Null-safety is nice, but it comes at the cost of either making the user’s program more complex or making the type system more complex (or both).

Quick Overview of Proposed Syntax

Types are declared with the type keyword. Types are just aliases, so if we have type Thingy = int, then we can use Thingy anywhere that int could be used.

We can have a sum type, which means a value with this type could have one of any of the types we specify. At runtime we would need to use pattern matching or some other mechanism to find out the specific type a variable has. We’d declare a type alias for a sum type like this:

type OneOfManyThingies = int | string | SomeClass;

You can think of | as meaning “or”.

I’m eventually going to add generics to the language, so something could also be declared like this:

type IntOrArray a = int | Array a;

Where a is a type. So if a function took IntOrSomethingElse string, that would be equivalent to int | Array string (where Array string is an Array of strings).

We also want to have product types. In most languages, product types most closely correspond to tuples (or a rudamentary form of classes or structs, where the fields are unnamed). They contain multiple values. Here are two examples:

type IntStringPair = int & string;
type Tuple a b = a & b;

You can think of & as meaning “and”.

We can also mix sum and product types, and this gives us algebraic data types:

type IntOrLabeledInt = int | string & int;

Note that & has higher precedence than |. So you can read the above as int | (string & int). It’s also useful to be able to tag items, in case you want disambiguate types that have the same value, but different meanings. For example, lets say we want a type that represents a value or an error message. We might do something like the following:

type ThingOrErrorMessage a = a | string;

What happens if a is a string? Then the type is just string | string and we can’t distinguish between a “good” string and the error message. In Haskell, it’s required that every option in the union have a tag. So it would look like this:

type ThingOrErrorMessage a = Thing a | ErrorMessage string;

You can also add the “tag” without any data, and use it sort of like an enum (in fact Rust actually just calls ADTs enums).

// Enum-ish thing can be used to declare "optional" type, as a replacement for null
type Maybe a = Nothing | Just a;

This is cool, but it has some drawbacks. Now we need to require that types start with a tag - otherwise Just a could be a generic class called Just that takes a type parameter, or it could be a tag Just followed by a generic type a. Requiring every union member have a tag means that we couldn’t have something like this:

function doStuff(maybeInt : null | int) : int | ErrorMessage {
    // does stuff
    ...
}

I would like it so that a user doesn’t have to declare all of the types in advance, so I’m not going to require unions to be tagged. The language aready has classes, so you could just do this:

class ErrorMessage {
    message : string;
}

type ThingOrErrorMessage a = a | ErrorMessage;

class Null {
// Contains no fields
}

type Nullable a = Null | a

Technically you would run into the same problem if we had Nullable Null or ThingOrErrorMessage ErrorMessage, but that would be a bad use of these type aliases. But one benefit is that we could reuse Null or ErrorMessage in other unions.

We can also still describe recursive datastructures fairly easily:

class ListNode a {
    content : a;
    next : LinkedList a;
}

type LinkedList a = Null | ListNode a

class TreeNode a { 
    value : a;
    left : Tree a;
    right : Tree a;
}

type Tree a = contents : Null | a | TreeNode a;

I honestly don’t think this is too bad, so it’s what I’m going to stick with. Some might say that having both product types and classes in the same language is redundant. I don’t think so. To me, there is no obvious way to have private fields in ADTs, so that’s one point in favor of something like classes. Also if we want to reference specific fields in a product type, we would have to pattern match on it or destructure it, both of which can get clunky if the object has a lot of fields. And as a nice bonus, we don’t have to explicitly give a name to every single union that we use in our programs.

Feature 1: Destructuring Assignment

So that’s how I see the type system working, more or less. Now I’ll get into some of the features for working with ADTs.

One things that makes product types easier to work with is destructuring. This is probably something people are familiar with from modern JavaScript. In order to denote that an object should use destructuring in assignment (since we don’t want to make type inference really complicated), I’d want to introduce the <- symbol:

function returnTuple() : int & string {
    return 11 & "This is part of a product type with two fields";
}

let num2, str2 <- returnTuple();
let tuple = returnTuple(); // Can also not destructure it, if we don't want to

We can also use a type alias:

type Tuple = int & string;

function returnTupleExplicit() : Tuple {
    return 11 & "This is also part of a product type with two fields";
}

let num2, str2 <- returnTupleExplicit();

That’s all well and good for product types, but for sum types, how would that work? Well, I would want it to give a compile error if we tried to do any of the above, so here’s my alternative.

Feature 2: Destructuring if

I want to avoid having to implement flow-sensitive typing, since, from what I understand, that’s a feature that’s pretty difficult to implement properly. The major languages to implement flow-sensitive typing are usually created by very smart people at big corporations, and I am a not-very smart guy making a language in his spare time.

As such, I think it might be cool to allow destructing assignment of union types in if statements. I’m thinking that the first statement of an if could be an assignment, but if the value of the destructure doesn’t match, the if statement evaluates to false. This would be less complicated than forcing the user to do pattern matching every time they need to look inside of a union, but would still be safe. Here’s an example of what I mean:

function defaultToZero(maybeInt : Nullable int) : int {
    if let i : int <- maybeInt; i == 5 {
        println(i, " is 5, btw");
        return i;
    else if let i : int <- maybeInt {
        println(i, " isn't 5, but it is an integer")
        return i;
    }
    return 0;
}

Or maybe we could rewrite it to take advantage of the basic type inference that del already has:

function defaultToZero(maybeInt : Nullable int) : int {
    let i = 0;
    if i <- maybeInt; i == 5 {
        println(i, " is 5, btw");
    else if i <- maybeInt {
        println(i, " isn't 5, but it is an integer")
    }
    return i;
}

This syntax isn’t too far off from what c-like languages do in a numeric for loop, and is similar to go’s ability to add assignment as the first item of an if statement. Technically the semantics are a little different, since match failure is also sort of part of the conditional, but I think it will feel familiar to most programmers.

The main drawback that I can immediately see is that it could make early returns more difficult. In the example above, it might be nicer to check for null, and if the value is non-null, in an ideal language it would be safe to start treating mabyeInt as an int in subsequent code. But now you’re in the world of flow-sensitive typing, which I don’t want to be in, as an implementer (as I mentioned, I’m a dumb guy with limited time). I’m not sure if there’s a good solution to this, but I think destructuring if is an ergonomic-enough contruct for most cases.

Feature 3: Pattern matching

Pattern matching is great for when there are multiple cases or conditions related to the types. It’s basically like the destructuring if above, but easier to read when the type could contain many different values. Here’s an example of what I would want:

type ManySuchCases = int | string | SomeCustomType | int & SomeCustomType

function printManySuchCases(misc : ManySuchCases) {
    switch misc {
        case i : int; i == 5 {
            println("five, btw");
        }
        case i : int {
            println("not five, but a number");
        }
        case str : string {
            println("'", str, "'");
        }
        case sct : SomeCustomType {
            println("Some fancy type");
        }
        case i : int, sct : SomeCustomType {
            println("an int, but also some fancy type");
        }
    }
}

Feature 4: Overloading Destructure

This is a funky one. I want to allow users to be able to overload different aspects of classes. Getters and setters are the obvious ones, as are arithmatic operators. But I think it would also be cool to allow overloading of destructuring. That way classes could be destructured or pattern matched on just like regular ADTs:

class Slice a {
    array : Array a;
    startIndex : int;
    endIndex : int;
    destructure() : Null | a | a & Slice a {
        let diff = endIndex - startIndex;
        if diff <= 0 {
            return null;
        } else if diff == 1 {
            return array[startIndex];
        } else {
            return array[startIndex] & new Slice(a, startIndex - 1, endIndex);
        }
    }
}

function recursiveSum(slice : Slice int) : int {
    switch slice {
        case _ : Null {
            return 0;
        }
        case val : int {
            return val;
        }
        case val : int, tail : Slice int {
            return val + sum(tail);
        }
    }
}

I’m not sure if any other language has something like this, but it seems cool to me! Hopefully I’m not missing some corner case about this feature being impossible to implement, because I really like it.

“Alas,” a third fellow chimed in, “‘strongly typed’ and ‘weakly typed’ are not rigorously defined academic terms,” and then linked to this wikipedia page.

“Shut up nerd,” the original fellow responded. The second fellow concurred, “I agree with you, but I agree with OP that you are a nerd and should shut up.”

Definitions are hard. The task of defining a term, such that it is consistently used in an unambiguous manner is hard. Difficult. A struggle. Tough stuff. You get it.

As such, I propose a piece of new unambiguous terminology that can be used to denigrate programming languages that you dislike. The set of all programming languages can be split into two disjoint sets: “nerdly typed” and “stupidly typed” languages. Given the following example:

function main() {
    x = 1
    print("Hello from a stupid programming language!")
    x.im_stupid()
}

A language implementation must be considered “stupidly typed” if its closest equivalent to the above pseudocode would print “Hello from a stupid programming language!” before printing out any other text. If a language satisfies this property, it is a stupid language, and if you use it you are probably an idiot. If it does not, then you are programming in a language for nerds, and you are probably a loser that doesn’t have any friends.

Now I know what you’re thinking. What if a language has a builtin im_stupid() method on integers? I’m sorry, but by the canonical definition, it is a stupidly typed programming language. And even worse, you’re a nerd for being so pedantic.

I’ve spent roughly a year building an interpreter for my own programming language called del. I’ve tried building interpreters a few times in the past, but I would always get hung up on building the parser, and so I didn’t spend much time learning about the ‘backend’ of interpreters. Going into building del, I knew this, so I hacked together a parser fairly quickly and started building out the bytecode compiler and a virtual machine. Recently I’ve been wondering how to improve the performance, and stumbled upon a fairly common optimization that most interpreters use called threaded code.

A Quick Introduction to Interpreters

Despite most people’s assumptions, interpreters actually often have compilation steps, even if they don’t compile to machine code. Most parse code into some intermediate tree-like representation called an abstract syntax tree (an AST), but then further transform that into what is called bytecode. Bytecode is like a fake, simplified assembly language that is then run by a virtual machine (VM). A VM is basically just a big loop over the bytecode. When it encounters an instruction, it executes a bit of code, moves on to the next instruction, and so on until the program terminates.

To give a brief illustration, the code 4 + 1 - 2 might be represented as an AST like (SUBTRACT (ADD 4 1) 2), and that could get converted to bytecode like PUSH 4; PUSH 1; ADD; PUSH 2; SUBTRACT;.

You might be wondering: why go to the trouble of doing an extra compilation step when you could just walk through the instructions in the AST? Well, many interpreters are initially written that way, since it’s the most intuitive and easy way to write an interpreter. The downside to this is that it tends to be much slower for long running programs. Ruby, for instance, was originally written in this way, but was replaced with a VM implementation for performance reasons.

The hand-wavy explanation I can give for why the VM implementation is faster is basically that an AST is a bunch of different chunks of memory linked together by pointers, whereas bytecode is just a big array of memory. Looping through a big contiguous array tends to be faster than dereferencing a bunch of pointers and jumping to different places in memory that may or may not be near each other. Someone more knowledgeable about how processors work could probably give a better explanation, but that’s the gist of it.

Interpreting bytecode is an optimization, but it’s still much slower than native code. How can we get more performance out of a bytecode interpreter? Well… you could do just-in-time compilation (JIT compilation), where you take that bytecode and compile it into actual machine code at runtime. That’s what the main implementations of Java, C#, and JavaScript (V8/NodeJS) do, and many interpreted languages have alternative implementations that do this (PyPy is a JIT compiled version of Python, for example). However this opens up a whole can of worms: different CPUs have different architectures, and require writing different assembly. And each operating system has its own set of unique system calls. Having to do a bunch of machine and os-specific compilation steps defeats one of the main benefits of an interpreter, which is that your code gets to be cross platform with little extra effort (or at least as cross-platform as the language that it is running on top of).

So if we don’t have the time, the patience, or the knowledge of assembly to do JIT compiling, can we still get more performance out of our interpreter? Yes! Well yes, if you’re writing in C or C++. But not on Windows. But otherwise, yes!

A Simple Example VM

Before we get into writing the threaded VM, let’s look at a simple example of a VM using a loop and switch. The following describes a simple VM that operates on a stack data structure. The VM has 6 operations:

• PUSH: Push a value onto the stack. Takes as an argument the value to push.
• ADD: Pop two values off of the stack and add them together.
• SUBTRACT: Pop two values off of the stack, and subtract the second value from the first.
• DUPLICATE: Make a copy of the value on the top of the stack and push it onto the stack.
• JUMP IF: Pop a value off of the stack. If it is greater than 0, jump to the given location. Takes as an argument the location in the bytecode where we want to jump to. Our bytecode is an array of integers, so the location is just the index of the element in the array that we want to jump to.
• RET: Terminate the program and return the value at the top of the stack.

We’ll define that using an enum as follows:

enum Bytecode {
    PUSH = 1,
    ADD = 2,
    SUBTRACT = 3,
    DUPLICATE = 4,
    JUMP_IF = 5,
    RET = 6
};

As I described above, most VMs will look like a loop over a big switch statement. Something like the following:

// Utility macros for manipulating the stack
#define pop() stack[--sp]
#define push(value) stack[sp++] = (value)
#define next() ip++

int looped(const int *bytecode)
{
    int stack[10] = { 0 };
    int sp = 1;
    int ip = 0;
    int temp1, temp2;
    while (true) {
        switch(bytecode[ip]) {
            case PUSH:
                next();
                push(bytecode[next()]);
                break;
            case ADD:
                next();
                temp1 = pop();
                temp2 = pop();
                push(temp1 + temp2);
                break;
            case SUBTRACT:
                next();
                temp1 = pop();
                temp2 = pop();
                push(temp1 - temp2);
                break;
            case DUPLICATE:
                next();
                temp1 = pop();
                push(temp1);
                push(temp1);
                break;
            case JUMP_IF:
                next();
                if (pop() > 0) {
                    ip = bytecode[ip];
                } else {
                    next();
                }
                break;
            case RET:
                goto end;
        }
    }
    end:
    return stack[sp - 1];
}

This works pretty well, and is decently fast. If we look at the compiled output of the looped version, we can see that each case jumps to the top of the loop (the .L2 label) and then has to check the current instruction against each possible instruction in the switch in order to determine where to jump to next.

Why not just jump straight to the next instruction? Because “goto considered harmful”? In many cases unstructured jumping can lead to hard-to-understand code, but in this scenario, it’s exactly what we need. Most people would prefer their interpreter be faster even if that means the source code of the interpreter is a little harder to understand.

By default, standards-compliant C does not actually provide a way of using goto-labels as values, so we need a gcc-specific extension in order for this code to work (though clang also supports this extension). The relevant documentation for this feature can be found here: labels as values. As of writing this, the documentation for this feature explicitly mentions that this is useful for writing fast interpreters!

#define cont() goto *(targets[bytecode[ip]])

int threaded(const int *bytecode)
{
    // Order of the items in this array must match the values of bytecode
    void *targets[] = { NULL, &&PUSH, &&ADD, &&SUBTRACT, &&DUPLICATE, &&JUMP_IF, &&RET };
    int stack[10] = { 0 };
    int sp = 1;
    int ip = 0;
    int temp1, temp2;
    cont();
    PUSH:
        next();
        push(bytecode[next()]);
        cont();
    ADD:
        next();
        temp1 = pop();
        temp2 = pop();
        push(temp1 + temp2);
        cont();
    SUBTRACT:
        next();
        temp1 = pop();
        temp2 = pop();
        push(temp1 - temp2);
        cont();
    DUPLICATE:
        next();
        temp1 = pop();
        push(temp1);
        push(temp1);
        cont();
    JUMP_IF:
        next();
        if (pop() > 0) {
            ip = bytecode[ip];
        } else {
            next();
        }
        cont();
    RET:
        goto end;
    end:
    return stack[sp - 1];
}

In our new threaded version, we can see that at the end of each case it simply loads the value in the array and jumps to it, mirroring what we see in our C code.

With these little helper macros that we’ve added, this isn’t much more difficult to read than the loop version, and removes all of the extra comparisons done by the switch in the looped version. It doesn’t seem too significant, but it adds up, especially if we’re iterating through these instructions billions of times. In the profiling I did on my machine using perf, it runs 20%-30% faster using clang or gcc when optimizations are enabled. Interestingly, it runs about as fast in both clang and gcc when no optimizations are enabled (-O0).

If you want to run this and time it yourself, the code can be found here. It includes some example bytecode that iterates from 1 to INT_MAX. If you want to hack on it, or just get a better sense of what it’s doing, I’d suggest enabling logging and changing INT_MAX to a small integer.

Check out the Lua interpreter if you want a real-world example of a threaded interpreter. It actually doesn’t look too different than what we have above. The main difference is that their VM uses a couple of helper macros to allow them to seamlessly integrate this feature while also allowing the compiler to toggle this optimization on and off, that way their code can enable this feature only for C compilers that support it. Checkout luaV_execute in lvm.c for their VM code, which uses the ljumptab.h macros to enable threaded code.

Addendum

I recently did some benchmarking of the Lua interpreter (and my own interpreter for del) comparing threaded code vs loop-and-switch, and I found that the threaded code often performed about the same or worse than the loop-and-switch. This was mainly based around 2 small benchmarks, so it’s possible that for a wider sampling of benchmark programs (or on a different machine, perhaps) that threading would perform better, but thought it would be worth mentioning this. Threading is enabled by default in Lua on compilers that support it, so presumably they benchmarked it and found that it was faster in general, but who knows. If you’re going to make a performance optimization, always benchmark it!