DEV Community: Ryan Bae

My New Language That’s Almost Done

Ryan Bae — Mon, 09 Feb 2026 20:10:51 +0000

I’ve been building a programming language for the past 3 months. Although it’s written in Swift, I’m planning to convert my Swift project to Rust. Here are the current specs:

Can declare variables, constants, and functions
Has type safety (no type inference)
Has a “pointer” system for references, but is still broken. This is NOT pointers from C, just pointers pointing to variables
Can declare structs

Sample code:

struct Foo {
  var x: number = 5
  fn test() => void {
    *self.x = 6
  }
  fn printIt() => void {
    print(*self.x)
  }
}

var foo: Foo = create Foo()
foo.test()
foo.printIt() // prints 6

GitHub link (don’t mind the username): https://github.com/Promiuns/Helix

How One Bad Download Corrupted a 5-month Project

Ryan Bae — Fri, 16 Jan 2026 04:59:27 +0000

I'm pretty sure you shouldn't be mixing laptop OS's and phone OS's, but here we are. This "bad download" was mainly due to trying to install UIKit onto my macOS project. The problem? UIKit doesn't exist in macOs; the equivalent is AppKit. I tried to force-download (or more accurately, try and do a -Wl... terminal command), and restarted my computer. It booted up perfectly fine, but when I opened the file... BAM! The dreaded error: linker command failed with exit code 1 (use -v to see invocation) popped up, not to mention the Canvas/Preview wasn't there. So remember (you probably already know this but...), please never try forcing UIKit to macOS; there's something called AppKit.

Progress on STAR (EOM)

Ryan Bae — Sun, 04 Jan 2026 23:03:59 +0000

Some Context

For one, I've changed the name from EOM (Explicit, Organized, Minimal) to STAR. Another thing, I've mostly finished the expression parser, the AST exec/eval, and now hacking away at the statements.

What Actually Changed?

Well, for starters, the language can now parse 2+3 to add(2, 3), and can now do struct initializers (expression: create Name(Arguments)) and function calls (expression: Name(Arguments)). The only things I need to add are now null terms (null(number), null(string)), and mix-fix operators (if _ then _ else _). For the AST, I need to implement the casting case, and the bridge thing for my language. While STAR is still in development, I made some concepts for STAR v2, v3, and probably v4. Here's some concept code:

// async
domain {
    print("Hello!")
}

print("World!") // prints immediately

// explicit scope
scope {
    let thingThatNeedsNewScope = some_function(":)")
    print(thingThatNeedsNewScope)
}

Here's some other ideas:
• new(_) makes a wrapper (domain or scope) without any external scope information
• persist and discard are manual lifetime keywords; you can extend a variable out of the scope, or delete it from anywhere.
• more math functions
• eventual C++ rewrite

Suggestions are greatly appreciated!

Why are Unary Operators so Hard?

Ryan Bae — Sat, 03 Jan 2026 07:06:28 +0000

So, if you've ever tried using parsers (whether to make your own language, or make a crazy-good calculator), you've probably been at least partially betrayed by unary operators. Stuff like -x, !flag, or counter++ are just hell for a normal-everyday parser. Don't get me wrong; parsers have made a way, but the different ways of how they do it is just... very complicated. But why? Why are unary operators so finicky and weird?

The Core Problem
Unary operators aren't like their binary counterparts (obviously). they take in one input, and spit out a value. But once you actually look at the tokens the parser gets, you'll start to see the problem. Take, for example, 2 + -x.
The lexer returns something like:

Number(2),
Operator(Add),
Operator(Minus),
Variable("x")

But how do we differentiate -u (unary subtraction) and -b? Let's start simple with Pratt parsing.

Pratt Parsing is a top-down parser where it starts not knowing the full expression, and it slowly iterates through the expression, gaining more context the more it reveals. Stuff like binary operators are easy; it's just binding power and waiting. but how does it parse -u? Well, Pratt Parsing uses led and nud: left-denotation and null-denotation. Basically, it's when an operator has a second number (led) or no second number (nud). When you're trying to use -u, then you would use the nud version of -.

For my parser, it uses disambiguation. Basically, if we had something like 7 + -5, it's going to check the last term. if it's a term starter , like an operator, it's a unary operator. If it's a term itself, it's a binary operator. But, you do need to check for all cases.

HAPPY NEW YEAR

Ryan Bae — Thu, 01 Jan 2026 08:11:44 +0000

Welcome to the new 2026! 2025 was a starter to the 2026 meal, so let's dig in and have another great year!

A New Kind of Parser Method

Ryan Bae — Thu, 01 Jan 2026 00:04:53 +0000

I don't know if you heard, but I'm pretty sure you know the method (or the concept) of Pratt parsing. To me, I don't really understand a lot of the concepts of Pratt parsing; binding power and NUD are way out of my league. Nevertheless, it's a really good parsing technique and it's used a lot of times. But I've made another parsing method, more simpler to understand, and at the similar level.

What's the Name?
The name for this parsing method is D-M parsing, short for disambiguation-merging parsing. More about the disambiguating and the merging later.

What's the general way of using it?
Say you have an expression like this:
2 + foo(4, 5) \* 4 / 23
Notice that the operators and the terms go in this pattern: term-operator-term-operator, and ends at a term (assuming parenthesis were already resolved). My technique uses that pattern to its advantage:
We can separate those two things into two separate lists; terms and operators. In terms, we list out all the terms in the expression in order, so the terms list would look like the following:
2, foo(4, 5), 4, 23
And same with the operators, so it looks like this:
+, \*, /
See another pattern? the terms list is always one element larger than the operator list. Using that, too, we can now make our tree.

How to Make the Tree
Now comes the magic- when you group the term elements by pairs (yes, they overlap), you can make the pairs the same as the operator list's length. i.e.:
(2, foo(4, 5)), (foo(4, 5), 4), (4, 23)
This is crucial for the binary operators.
Now that we have normalized the lists to one length, we pass through the tree. We check the highest precedence (in this case, * and /), and start pairing from there. Now, if we list the operator and term's index, and match the first * with the corresponding pair- foo(4, 5), 4, we get our first tree- [foo(4, 5), 4]{*} (note: the curly braces is the operator, the square braces are for the arguments). We then remove the used * and the pair with [foo(4, 5), 4]{*}.
Currently, we have:
2, [foo(4, 5), 4]{*}, 23 as our terms list. now, we check for the next element with the same precedence; /.
And yeah, keep repeating the process; you should get:
[2, [[foo(4, 5), 4]{*}, 23]{/}]{+} as the final tree, or in coding terms-

add (
    2,
    divide (
        multiply (
            foo(4, 5),
            4
        ),
        23
    )
)

Okay, But Are There Any Hidden Things?
Yes, of course! This way of parsing needs a LOT more than just two lists and a grouper; we need a disambiguation part and a merging part. The disambiguation part is for splitting - into two core types, -u (unary) and -b (binary), splitting . into two core types, .n (numeric/decimal point) and .m (member access), and splitting ( into two core types, (n (numeric/grouping opening) and (c (function call).

The merger, though, that is one of the hard parts. you need to merge -u x into -x, a .m b into a.b, and foo .m bar (c 23, 24 ) into foo.bar(23, 24). its basically a mini-parser; except for only functions (and maybe a few mix-fix here and there); nothing else.

Once those two core components have ran, the final output is a list full of terms, operators, and group openers/closers. And, like any other parser, recursively parse those parentheses. Now, with your fully-parsed AST, you're good to go for an expression parser!

Big Project I'm making

Ryan Bae — Sun, 21 Dec 2025 04:15:10 +0000

What is My Project?
It's a language called EOM thats written in Swift. It's a programming language, and it's about 30% done. It uses its own paradigm (because OOP has various pitfalls like the diamond problem and the fragile base class), and it's going to have similar but different enough syntax from Swift.

Okay, but what does the syntax look like?

// examples
// if statements
if x == 5 {
    print("Hello, World")
} else {
    print("Bye, World")
}

// paradigm
struct A {
    var foo: number
}

copy A => B {
    add var bar: string = "This is a test"
}

let temp: B = B()
print(temp.bar) // prints "This is a test"

Why are you making it?
This project is for my 2026 submission for the Swift Student Challenge (I haven't done it before, so this is first time, lol).

I'm still working on the AST design, but I'm starting to get into the parser side, and I'm open to feedback from people interested in programming language design. Thank you!