In earlier articles, I introduced this compiler project, wrote some Roc code to load an input file, and started implementing a tokenizer with error handling.
I think I need to admit that I have absolutely no clue how to estimate how long a blog article is going to be. I thought “build a compiler” would be one article. And then I thought “build a tokenizer” would be one article. sigh
I swear we’ll be done with tokenizing at the end of this post. But first we’ll take a detour to have a look at Roc’s very elegant built-in testing syntax.
Reminder: You are reading content that took a great deal of effort to craft, compose, and debug. If you appreciate this work, consider supporting me on Patreon or GitHub.
In part 1 and part 2 of this series, I introduced the project and we wrote some Roc code to load an input file and save the compiled result to a different file.
Note: Other articles in this series are collected here.
However, we are a long ways from actually having that compiled result available! This article introduces the phases involved in writing a compiler and focus on implementing the first phase, known as lexical analysis or tokenizing.
My latest hair-brained project is a WAT-to-Wasm compiler written in the Roc programming language. I explained my (ir)rationale for the project in Part 1 of this series, which also included an introduction to the technologies we’ll be using.
Note: Other articles in this series are collected here.
In this article, we’ll get started writing some Roc code. We won’t get to the point where we are doing anything with WAT or Wasm, yet, but we will be able to load an input file and parse some command line arguments.
I’ve been curious about the Roc programming language for a while now, but I haven’t had/taken the time to really dig into it. I’ve read through the tutorial several times, but only yesterday did I actually sit down and install Roc and implement the tutorial. Today, I woke up with the ridiculous idea to build a compiler in the language.
A simple compiler, to be clear.
Dexie Cloud was released publicly today, and I love this product so much that I want to lend my voice to the marketing effort.
Dexie.js is an incredible library for interacting with IndexedDB in the browser. It wraps the sometimes-obtuse (and oft-buggy) IndexedDB APIs with much more developer-friendly interfaces. And it is fully reactive; if you change something in the database, your React, Svelte, Vue, Angular, or Solid.js (Solid support is weak) app will live update all by itself! It’s a truly heavenly coding experience.
However, web users do not live in a vacuum, and storing things in IndexedDB is fraught. The browser may delete that data on a whim, and who among us only has one device these days? You might be able to use IndexedDB as a cache, but it can’t be your source of truth.
Until today.
My wife and I have been working on Fablehenge—a writing app for novelists—for several years. It had been a free time project where we’d push hard over a few weekends, then let it sit idle for a couple months perhaps tinkering in the evenings when we had a bit of time.
At the beginning of this year, I decided to take a sabbatical, which was supposed to involve cutting new hiking trails and woodworking. While it has done that, I found I’ve also been working on Fablehenge (more or less) full time.
