Drew Youngwerth
September 01, 2022

The final phase of our compiler is code generation. This phase takes the AST and converts it to a set of executable instructions. In our case, WebAssembly. To accomplish this, we are going to use a popular WebAssembly compiler toolchain called binaryen.
Binaryen does most of the heavy compiling tasks for us. Tricky optimizations like dead-code removal, code folding, and more are all handled out of the box. Thanks to binaryen, we can make a powerful language with very little code.
This is the third article in the Build a programming language series. If you’re just starting out, start with the first post here before continuing on.
One of the trickiest tasks in code generation is what to call the code generation function. For this article, I have opted to call the main function compile. The compile function will take our root AST (a BlockNode) and return a new binaryen.Module. The binaryen.Module exposes functions that can optimize and emit wasm in various formats.
Here's the outline:
Copied!
// src/compiler.mtsimport binaryen from "binaryen";import { AstNode, BlockNode, IdentifierNode } from "./types/index.mjs";export const compile = (block: BlockNode): binaryen.Module => {// Creates a new binaryen module that our helper functions will fill inconst mod = new binaryen.Module();// The function map is used to track all the functions and their types. More on this laterconst functionMap = generateFunctionMap(block);// This function registers all the standard library functions we'll include with our language.// This includes functions like add, subtract, etc.registerStandardFunctions(mod, functionMap);// This is where the magic happens. Because `BlockNode` is an expression, this// function can recursively compile every instruction in a wispy program filecompileExpression({expression: block,mod,functionMap,parameters: new Map(),});// Finally, we return the binaryen modulereturn mod;};
Next we define the generateFunctionMap function. This function crawls the entire expression
tree to find and register function definitions. Its important we do this before actually
compiling the functions as some functions may call other functions before they've been defined.
The return type of generateFunctionMap is a map where the key is the function name and the
value is an object containing all the important information about the function the compiler
needs to know about. For now, all we need is returnType.
Here’s the return type definition:
Copied!
// src/compiler.mtstype FunctionMap = Map<string, { returnType: number }>;
Now that we have defined our return type, we can define the actual function:
Copied!
// src/compiler.mtsconst generateFunctionMap = (block: BlockNode): FunctionMap => {// Preview the first node (i.e. expression) of the blockconst firstNode = block.expressions[0];// If the first node is an identifier and the identifier is "fn", then we know this block represents a function definition.if (isNodeType(firstNode, "identifier") && firstNode.identifier === "fn") {// Grab the function identifier / name, and it's return type. This is the second expression of// the function definition, a typed identifier.const { identifier, returnType } = getFunctionIdentifier(block); // We'll define this next// Return the function mapreturn new Map([[identifier, { returnType }],// It's possible this function may contain function definitions inside of it. So we// We put all the remaining expressions of the function into a new block and scan it// then we merge the resulting map with this one....generateFunctionMap({ type: "block", expressions: block.expressions.slice(3) }),]);}// A block can contain multiple expressions. So, we must scan each one to see if it is a function// definition. The root `BlockNode` for instance, will almost always have multiple functions.return block.expressions.reduce((map, expression) => {// Only block expressions can be functionsif (expression.type === "block") {return new Map([...map, ...generateFunctionMap(expression)]);}// We can ignore all other expressionreturn map;}, new Map());};
Onto getFunctionIdentifier we called earlier. This function is simple. It takes a BlockNode, ensures that the second identifier is a TypedIdentifierNode, and then returns the identifier
and return type:
Copied!
// src/compiler.mtsconst getFunctionIdentifier = (block: BlockNode) => {// Grab the second expressionconst node = block.expressions[1];// Ensure the expression is a typed identifierif (!isNodeType(node, "typed-identifier")) {throw new Error("Expected typed function name");}return {identifier: node.identifier,// We have to map the return type to a type binaryen understands.returnType: mapBinaryenType(node.typeIdentifier),};};
As noted in the getFunctionIdentifier function, Binaryen doesn't understand what type
the string typeIdentifier is. To handle this we have to map our defined types to binaryen types. For now, we'll just support i32 and f32. Thankfully binaryen uses the same nomenclature we do. So the map function is pretty simple:
Copied!
// src/compiler.mtsconst mapBinaryenType = (typeIdentifier: string): binaryen.Type => {if (typeIdentifier === "i32") return binaryen.i32;if (typeIdentifier === "f32") return binaryen.f32;throw new Error(`Unsupported type ${typeIdentifier}`);};
getFunctionIdentifier Made a call to a new function, isNodeType. This function is
essentially the same concept as the isTokenType function we defined in the parsing article, only for ASTNode instead of Token.
Here's the definition:
Copied!
// src/compiler.mtsexport const isNodeType = <T extends AstNode["type"]>(item: unknown,type: T): item is Extract<AstNode, { type: T }> => {return (// Ensure the type exists!!item &&// Ensure the type is an objecttypeof item === "object" &&// Cast the type as a record, so TypeScript doesn't get mad at us and then compare the// type field with the type parameter. If they are equal, we know the node is the// the type we were looking for.(item as Record<string, unknown>)["type"] === type;)};
With the mapper finished we can start generating some code.
The compileExpression function is where we really start to make use of binaryen to model
the generated machine code. Because of the tree structure of an, ahem, abstract syntax tree,
compileExpression is highly recursive. This is one of my favorite things about programming
languages, their patterns tend to lend themselves to elegant recursive functions with high
levels of code re-use.
Let's start with defining the parameters of compileExpression. We will need to pass the
binaryen.Module and the functionMap we created earlier, the actual expression we are
compiling, and any parameters of the function this expression may be a part of (if it's inside)
of a function. When there are more than two parameters of a function it can be difficult
to visually keep track of what is what. So I like to make it clear by grouping them together
in an object. This enforces labeling the parameters on call and as a result, improves code
readability.
Here's the interface of that object:
Copied!
// src/compiler.mtsinterface CompileExpressionOpts {expression: AstNode;mod: binaryen.Module;functionMap: FunctionMap; // We defined this earlierparameters: ParameterMap; // Defined below.}// A map where the key is the parameter identifier and the value is the important information// required by binaryen to fetch the parameter down the linetype ParameterMap = Map<string, { index: number; type: number }>;
Now that we have the options for compileExpression defined, we can define the actual function. compileExpression takes CompileExpressionOpts as a parameter and returns a number. The job of this function is to take an expression and determine what type of expression it is, from there it can pass the expression to another compiler function that can handle that specific type of expression.
Why return a number? When we build an expression with
binaryenit returns a number as an identifier for that expression. This allows us to compile an expression ahead of time and then reference that expression later down the line.
Here's the definition:
Copied!
// src/compiler.mtsconst compileExpression = (opts: CompileExpressionOpts): number => {// Grab the expression and the binaryen module (mod) from the options.// The other fields are used by child function callsconst { expression, mod } = opts;// Map the expression node to it's corresponding specific compilerif (isNodeType(expression, "block")) return compileBlock({ ...opts, expression });// Numbers are simple enough to compiler that we can just inline the compiler here.// They are represented as constantsif (isNodeType(expression, "int")) return mod.i32.const(expression.value);if (isNodeType(expression, "float")) return mod.f32.const(expression.value);if (isNodeType(expression, "identifier")) return compileIdentifier({ ...opts, expression });// Throw a helpful error message if we don't recognize the expressionthrow new Error(`Unrecognized expression ${expression.type}`);};
Let's define the compileBlock functions. Because this function is also compiling an expression,
we can re-use the previously defined CompileExpressionOpts, but we'll narrow the expression
field to the BlockNode type, since we know we are compiling a block by the time this function is called:
Copied!
interface CompileBlockOpts extends CompileExpressionOpts {expression: BlockNode;}const compileBlock = (opts: CompileBlockOpts): number => {// We re-map the expression field to block here for clarity.const { expression: block, mod } = opts;// When a block has multiple expressions and the first one is an identifier, that means// the block is actually a function call.if (isNodeType(block.expressions[0], "identifier") && block.expressions.length > 1) {// If it is a function call, transfer responsibility to the `compileFunctionCall` function (defined next)return compileFunctionCall(opts);}// This is where the recursive beauty starts to show. Since every value of a block// is an expression, we can map each one back to the compileExpression function.const expressions = block.expressions.map((expression) => {return compileExpression({ ...opts, expression });});// Now we generate the machine code by calling the block function of binaryen// This function takes a block name, an array of compiled expressions, and a block return type.// Named blocks are mostly useful for looping constructs like `for` and `while`. In this// case we can pass null as we're not compiling a loop construct. Additionally, we can// pass `auto` as the type since binaryen is smart enough to determine the return type// of blocks automatically.return mod.block(null, expressions, binaryen.auto);};
Note: If you're curious to see how looping works in binaryen / WebAssembly works, check out my blog post on the subject here. Spoiler alert, its pretty weird.
The last simple expression we'll compile in this section is the identifier expression. If
compileExpression was passed a lone IdentifierNode it means that the expression evaluates
to the value of the identifier. In wispy, we don't have variables and function identifiers are
caught before the could've been passed here. That means the only thing IdentifierNode can
resolve to is a parameter.
Here's the definition:
Copied!
interface CompileIdentifierOpts extends CompileExpressionOpts {expression: IdentifierNode;}const compileIdentifier = (opts: CompileIdentifierOpts): number => {// We remap expression to node to keep our lines a little shorterconst { expression: node, parameters, mod } = opts;// Since we know the identifier has to be a parameter, we look it up in our// parameter map. Don't worry, we'll define the parameter map in the next sectionconst info = parameters.get(node.identifier);if (!info) {throw new Error(`Unrecognized identifier ${node.identifier}`);}// Finally, we use the local.get instruction to return the parameter value.// Binaryen needs to know the parameters index and type. We'll get into// the index when we define our parameter mapping function.return mod.local.get(info.index, info.type);};
The final expression type left to compile is a function call. This is interesting enough to warrant its own section.
In wispy function calls are blocks with multiple expressions where the first expression is an
identifier. The job of compileFunction is to determine which function is being called, what
its parameters and return type are, and finally, building the call instruction with binaryen.
Here's the definition:
Copied!
// src/compiler.mts// Because function calls are blocks, we can re-use CompileBlockOptsconst compileFunctionCall = (opts: CompileBlockOpts): number => {const { expression, functionMap, mod } = opts;// The first expression of a function call is the functions identifierconst identifierNode = expression.expressions[0];// Here we just ensure the identifierNode is *actually* an identifier. Otherwise we throw an error.if (!isNodeType(identifierNode, "identifier")) {throw new Error("Expected identifier when compiling function call");}// Next we create a reference to what the actual identifier isconst identifier = identifierNode.identifier;// If the identifier is "fn", the function we are calling is the function to define functions!// That's right! Functions are created by another function. Pretty neat if you ask me.if (identifier === "fn") return compileFunction(opts); // We'll define this next// Ifs are special functions. They may or may not have an else block. Binaryen needs to know// if the else block exists at compile time, so we have a special if compiler for this.if (identifier === "if") return compileIf(opts); // We'll define this later// Every other function is either part of the standard library, or is defined// within the wispy code itself.const functionInfo = functionMap.get(identifier);if (!functionInfo) {throw new Error(`Function ${identifier} not found`);}const params = expression.expressions// Every other expression in the block are parameters to the function, so we compile them// and then pass them to the call.slice(1).map((expression) => compileExpression({ ...opts, expression }));// Now we use binaryen to construct the call expression. The first parameter// is the functions identifier, the second are the compiled parameter expression,// and the third is the return type which has already been determined by generateFunctionMapreturn mod.call(identifier, params, functionInfo.returnType);};
Let's define the compileIf function before we move onto the compileFunction... function.
Copied!
// src/compiler.mtsconst compileIf = (opts: CompileBlockOpts): number => {const { expression, mod } = opts;// The first expression, expression.expressions[0], is the "if" identifier, we don't need// to do anything with it since we already know we are compiling an if expression// The second expression is the if conditionconst conditionNode = expression.expressions[1];// The third expression is the ifTrueNode, it's what is executed if the conditionNode evaluates to// trueconst ifTrueNode = expression.expressions[2];// Finally the fourth expression (which may or may not exist) is what is executed if the condition// evaluates to falseconst ifFalseNode = expression.expressions[3];// Compile the condition expressionconst condition = compileExpression({ ...opts, expression: conditionNode });// Compile the ifTrue Expressionconst ifTrue = compileExpression({ ...opts, expression: ifTrueNode });// Check to see if the ifFalseNode exists, if it does, compile it, otherwise set ifFalse to undefinedconst ifFalse = ifFalseNode ? compileExpression({ ...opts, expression: ifFalseNode }) : undefined;// Finally we use binaryen to compile the if expressionreturn mod.if(condition, ifTrue, ifFalse);};
Function definitions are a whole lot like function calls, so the function structure is pretty similar.
We take CompileBlockOpts and return a number (the binaryen expression reference).
Here's the definition:
Copied!
// src/compiler.mtsconst compileFunction = (opts: CompileBlockOpts): number => {const { expression: block, mod } = opts;// We need to tell binaryen what the identifier and return type of the function is// Thankfully, we already wrote a function for that, getFunctionIdentifier. We// could also have just looked up this information with the functionMap, but// this is more fun.const { identifier, returnType } = getFunctionIdentifier(block);// Next we grab the function parameters. This is the third expression of the functionconst { parameters, parameterTypes } = getFunctionParameters(block); // Defined later// The rest of the expressions in the function are the functions block. So we create// a new BlockNode from the remaining expression.const body = compileBlock({...opts,expression: {type: "block",expressions: block.expressions.slice(3),},// We need to pass the parameters of this function, so they can be referenced in child// expressionsparameters,});// Now we register the function with binaryen. Binaryen takes the function identifier,// an array of parameter types (each item being the type of parameter in order),// the function's return type, a list of variable types (wispy doesn't have any, so we pass an empty array)// and finally the compiled body of the function.mod.addFunction(identifier, parameterTypes, returnType, [], body);// To make things easy we export every single function defined in a wispy file// so it can be called by the WebAssembly host.mod.addFunctionExport(identifier, identifier);// Because function definitions are *technically* expressions that can be a part of another function// body, we need to return an expression pointer. For this, we just return a nop (do nothing instruction),// to make things consistent.return mod.nop();};
Now, let's define the getFunctionParameters function. This function takes the function BlockNode, that is, the entire unmodified function definition, and extracts its parameters. The function returns two values, parameters and parameterTypes.
The first returned value, parameters, is a map where the key is the parameter identifier, and the value is the information needed to access the parameter down the line within the function body.
The second returned value is an array of binaryen types. There is one type for each defined parameter, and they must remain in the order they are defined. This is because binaryen doesn't reference parameters by their names, instead it references them by the index of the array in which they are defined. Don't worry if this is confusing to you, the code should make things a little more clear. If you need, refer to the compileIdentifier definition, to get a better
understanding of how this works in practice.
Here's the definition:
Copied!
// src/compiler.mtstype ParameterMap = Map<string, { index: number; type: number }>;const getFunctionParameters = (block: BlockNode) => {// The parameters are defined in the third expression of the function definitionconst node = block.expressions[2];// Check to make sure the third expression is a blockif (!isNodeType(node, "block")) {throw new Error("Expected function parameters");}// Now we reduce the parameters into a parameter map, and a list of binaryen typesconst { parameters, types } = node.expressions.reduce((prev, node, index) => {// First, ensure that the node is a typed-identifier. Every parameter must be a// typed identifier, therefore, every node in this reducer must be a typed identifier.if (!isNodeType(node, "typed-identifier")) {throw new Error("All parameters must be typed");}// Determine the correct binaryen type of the parameterconst type = mapBinaryenType(node.typeIdentifier);// Add the parameter's type to the list of types we've defined so farconst types = [type, ...prev.types];// Now add the parameter to the parameter map. We save the parameters index and type.// The index and type is used binaryen to access the parameter when it is used// later in the function bodyconst parameters = new Map([[node.identifier, { index, type }], ...prev.parameters]);// Return updated parameters map and types arrayreturn {parameters,types,};},// Here we are setting the starting values for our reducer function and casting the default// type so typescript can correctly infer the `prev` parameter type{ parameters: new Map(), types: [] } as {parameters: ParameterMap;types: number[];});// Finally we return the parameter map and the parameterTypesreturn {parameters,// Note: parameterTypes is a number, instead of an array of numbers as you'd expect.// So we have to use binaryen.createType to create a new type that is referenced// the mod.addFunction function. This is one inconsistency with the binaryen API. Parameters// are defined as a number, and variables are defined as an array of numbers. I'm sure there// is a reason for this, but I don't know what that reason is.parameterTypes: binaryen.createType(types),};};
Now all that's left is to define the standard library. This part of the code isn't super interesting. We are essentially just mapping primitive WebAssembly instructions to a name to be referenced within wispy.
Here's the definitions. The only important information is the name we are associating with each instruction:
Copied!
// src/compiler.mtsconst registerStandardFunctions = (mod: binaryen.Module, map: FunctionMap) => {const { i32, f32 } = binaryen;const { i32: i32m, f32: f32m } = mod;const common = { mod, map };registerLogicFunction({ name: "lt_i32", type: i32, operator: i32m.lt_s, ...common });registerLogicFunction({ name: "gt_i32", type: i32, operator: i32m.gt_s, ...common });registerLogicFunction({ name: "eq_i32", type: i32, operator: i32m.eq, ...common });registerLogicFunction({ name: "lt_f32", type: f32, operator: f32m.lt, ...common });registerLogicFunction({ name: "gt_f32", type: f32, operator: f32m.gt, ...common });registerLogicFunction({ name: "eq_f32", type: f32, operator: f32m.eq, ...common });registerMathFunction({ name: "add_i32", type: i32, operator: i32m.add, ...common });registerMathFunction({ name: "sub_i32", type: i32, operator: i32m.sub, ...common });registerMathFunction({ name: "mul_i32", type: i32, operator: i32m.mul, ...common });registerMathFunction({ name: "add_f32", type: f32, operator: f32m.add, ...common });registerMathFunction({ name: "sub_f32", type: f32, operator: f32m.sub, ...common });registerMathFunction({ name: "mul_f32", type: f32, operator: f32m.mul, ...common });registerMathFunction({ name: "div_f32", type: f32, operator: f32m.div, ...common });};const registerMathFunction = (opts: {mod: binaryen.Module;name: string;type: number;operator: (left: number, right: number) => number;map: FunctionMap;}) => {const { mod, name, type, operator, map } = opts;return registerBinaryFunction({mod,name,paramType: type,returnType: type,operator,map,});};const registerLogicFunction = (opts: {mod: binaryen.Module;name: string;type: number;operator: (left: number, right: number) => number;map: FunctionMap;}) => {const { mod, name, type, operator, map } = opts;return registerBinaryFunction({mod,name,paramType: type,returnType: binaryen.i32,operator,map,});};const registerBinaryFunction = (opts: {mod: binaryen.Module;name: string;paramType: number;returnType: number;operator: (left: number, right: number) => number;map: FunctionMap;}) => {const { mod, name, paramType, returnType, operator, map } = opts;mod.addFunction(name,binaryen.createType([paramType, paramType]),returnType,[],mod.block(null,[operator(mod.local.get(0, paramType), mod.local.get(1, paramType))],binaryen.auto));map.set(name, { returnType });};
Now that we have finished our compiler, we can finally run our code.
First, replace the contents of src/index.mts with this:
Copied!
// src/index.mts#!/usr/bin/env nodeimport { readFileSync } from "fs";import { compile } from "./compiler.mjs";import { lex } from "./lexer.mjs";import { parse } from "./parser.mjs";const file = process.argv[2];const input = readFileSync(file, "utf8");const tokens = lex(input);const ast = parse(tokens);// !! New !!const mod = compile(ast);// This is sneakily where the code gen is *actually* happeningconst binary = mod.emitBinary();// Use the standard WebAssembly API to convert the wasm binary to a compiled module// our host NodeJS/v8 can useconst compiled = new WebAssembly.Module(binary);// Build the instance, here you would add any external functions you might want to import into// the WebAssembly moduleconst instance = new WebAssembly.Instance(compiled, {});// Finally, run the main function and log the result. We have to cast instance.exports to any// The standard TypeScript types appear to be wrong.console.log((instance.exports as any).main());
Now build and run project:
Copied!
npx tscwispy example.wispy
If all goes well (and you passed the number 15 to fib), you should see the number 610 in the
output of your console. If so, you've done it, you've made a working WebAssembly language. Congrats!
A full copy of the wispy language implementation is available under an open-source license at https://github.com/drew-y/wispy.

How Top Notification Platforms Handle Quiet Hours & Delivery Windows in 2026
No platform offers per-template delivery windows in 2026—it's either per-workflow (Customer.io, Knock), per-campaign (Braze), or global settings. This comparison shows exactly how six platforms handle quiet hours and send time controls based on their documentation and API specs. Braze leads on AI timing (23% open rate lift from Intelligent Timing across their customer base). Novu is the only platform letting subscribers set their own delivery windows. Customer.io and Knock require manual workflow configuration. OneSignal's strength is push-specific optimization across 300K+ apps. Courier combines per-node flexibility with API control. Includes feature matrix, timezone handling, and frequency capping differences.
By Kyle Seyler
January 16, 2026

Notification Observability: How to Monitor Delivery, Engagement, and Provider Health
Notification observability is the practice of monitoring notification delivery, engagement, and provider health using the same tools and discipline you apply to the rest of your application infrastructure. It means tracking whether messages are delivered, opened, and acted on across email, SMS, push, and in-app channels, then surfacing that data in dashboards alongside your other application metrics. Key metrics include delivery rate by channel, bounce and failure rates, provider latency, open rate trends, and click-through rates by template. Teams can build notification observability through DIY webhook handlers that pipe provider events to Datadog or Prometheus, log aggregation from application send logs, or notification platforms with built-in observability integrations. This matters most for multi-channel systems, business-critical notifications like password resets and payment confirmations, and teams using multiple providers with fallback routing.
By Kyle Seyler
January 15, 2026

SMS Opt-Out Rules in 2026
TCPA consent rules changed in April 2025. Consumers can now revoke consent using any reasonable method, including keywords like "stop," "quit," "end," "revoke," "opt out," "cancel," or "unsubscribe." Businesses must honor opt-out requests within 10 business days, down from 30. The controversial "revoke all" provision, which would require opt-outs to apply across all automated messaging channels, has been delayed until January 2027 and may be eliminated entirely. SMS providers like Twilio handle delivery infrastructure and STOP keyword responses at the number level. They don't sync opt-outs to your email provider, push notification service, or in-app messaging. That cross-channel gap is your responsibility. Courier provides unified preference management that enforces user choices across SMS, email, push, and chat automatically.
By Kyle Seyler
January 13, 2026
© 2026 Courier. All rights reserved.