**Code Blocks currently only viewable in dark mode... :P** ## Starting with the Spec I first starting creating the language blindly, managing to create a simple lexer, parser, and abstract syntax tree (AST) for the simple program `return ;`, creating NASM X86 assembly code. This proved to be a mistake as despite managing to get that far, having to carve out the syntax of the language from nothing while learning the implementation of the design proves extremely difficult especially with no direction or goal in mind for the language. As such I decided to stop all progress and first define the syntax of the language before any more implementation. This turned out to be a good decision as many syntax decisions are rarely isolated. Taking the example of struct initialization: I originally wanted Python-style slicing using `:` as the separator: ```mirage var sub = nums[2:5]; ``` But I also wanted named field initialization using `:` for clarity: ```mirage var pos = Vec2 {x: 0.0, y: 0.0}; ``` Had I not started with syntax decisions, I would've been locked into the `:` syntax for slicing and forced to use a less readable syntax for field initialization in structs causing me to have to rewrite the parser and spec. By deciding on syntax early, I was able to resolve these conflicts in a relatively short amount of time rather than having to rewrite everything down the line. A similar thing happened with error handling and the type system where I wanted `Option` for safe array access via `.get()`. Then I wanted `Result` for fallible functions. These are both just algebraic enums under the hood which meant I also needed enums with associated data before either of those could be defined. Had I implemented `Option` first without thinking through enums I probably would've special-cased it when writing the compiler, then had to rip it all out when reaching `Result`. Creating the spec first meant I was forced to think through and resolve these decisions without having to deal with sunk cost when changing my mind. --- ## Stealing from Go I'm a huge fan of how Go handles concurrency: ["Don't communicate by sharing memory, share memory by communicating"](https://go.dev/blog/codelab-share). Basically instead of having multiple threads touching the same data, you pass ownership of data through typed channels. ```mirage var ch = channel(); var handle = spawn { ch.send(computeGradients(batch)); }; var gradients = ch.recv(); handle.join(); ``` When sending data over a channel in Mirage, the sender loses ownership. As a result, two tasks can't modify the data at the same time, getting rid of many unwanted behaviors that come with concurrency. --- ## Robbing Rust To avoid the headache and work of figuring out how to create a garbage collector (as well as the performance cost that comes with a garbage collector), I've decided to unapologetically steal Rust's memory management: In Mirage, every value has exactly one owner at a time tracked statically by the compiler. ```mirage var x = Tensor { shape: [784, 128] }; var y = x; // x is moved, no longer valid // x.shape; // compiler error ``` In the case you need raw pointer access, it must be placed in an `unsafe` block for cases where it's needed. ```mirage unsafe { var p *int = &x; *p = 10; } ``` Rust also proved that exhaustive match expressions are better than switch statements. As such Mirage uses them as the primary branching construct where the compiler requires every case to be handled: ```mirage match result { Ok(value) -> process(value), Err(e) -> eprintln("failed: ${e}"), } ``` --- ## Other Decisions Faced **No null.** Tony Hoare (null's creator) called it his billion dollar mistake and I've decided to omit it from the Mirage language. Absence is expressed through `Option` (stealing from Rust again): ```mirage var x Option = None; var y int = 5; // always non-null, compiler guaranteed match nums.get(10) { Some(x) -> process(x), None -> log("not found"), } ``` You cannot use a value that might not exist without handling the `None` case first preventing null pointer exceptions or "None has no attribute" seen in Java and Python respectively. **Result instead of exceptions.** In Java or Python, you typically don't have any idea a function throws until it does so at runtime. In Mirage, if the function can fail it will return `Result` as seen: ```mirage func readFile(path string) -> Result { // ... } ``` The `?` operator handles propagation without boilerplate: ```mirage func loadConfig(path string) -> Result { var text = readFile(path)?; // early return on Err return Ok(parse(text)?); } ``` **No C-style for loops.** Stepped iteration uses a third argument to `range` (stealing from Python): ```mirage for i in range(0, n, 2) { } // equivalent to for (int i = 0; i < n; i += 2) ``` --- ## Where I'm at now As of right now the compiler supports function declarations, `var` and `const`, return, println, integer arithmetic, string literals, and bool literals. The pipeline is: source → lexer → recursive descent parser → LLVM IR → clang → native binary. I chose to switch to LLVM IR rather than writing NASM assembly code as the backend gives cross-architecture compatibility for free, ensuring the same Mirage source compiles to x86, ARM64, and RISC-V (saves me a lot of work... :P) Full spec and source on [GitHub](https://github.com/StreetLamp05/Mirage). --- ## The Theory of Computing Connection I was originally inspired to create Mirage by my Theory of Computing Professor [Dr. Hollingsworth](https://www.cs.uga.edu/directory/people/bill-hollingsworth) who created the [Grafstate Language](https://grafstate.com/user/login/) to help teach students, which to this day has been my favorite computer science class. Many of the topics from that class show up directly in the implementation of the language. Deterministic Finite Automata (DFAs) are in the lexer where each token type is recognized by a finite automaton classifying character sequences into identifiers, operators, literals, keywords (more of a PDA as it uses a call stack tho). Context Free Grammars (CFGs) are in the parser where the grammar of Mirage is a context-free grammar. --- *The spec document in the repo walks through every decision and the reasoning behind it* [Mirage Spec](https://github.com/StreetLamp05/Mirage/blob/main/Mirage_Spec_v0.1.md)

Posts tagged “Language Design”

Designing Mirage: A Compiled Language from Scratch