DEV Community: MoonBit

Build a Mobile Game with MoonBit

MoonBit — Fri, 06 Mar 2026 06:52:35 +0000

MoonBit compiles to native code (via C) with a strong type system and familiar syntax. Raylib is a minimal C library for games — window, drawing, input, and audio with zero boilerplate. Together, they let you build mobile games with native performance and a tiny package — no engine runtime, no garbage collector pauses. Since both MoonBit and Raylib compile to standard C, this stack theoretically runs on iOS as well, but this tutorial focuses on Android. You'll go from zero to a working Flappy Bird on your phone.

Because MoonBit compiles to standard C code, the same game code can target multiple platforms by swapping the compilation toolchain: gcc or clang for desktop, emcc (Emscripten) to WebAssembly for browsers, or the Android NDK to cross-compile into a native .so shared library packaged into an APK. The core game logic requires no per-platform rewrites — though mobile targets like Android may need minor input adaptations, such as replacing keyboard events with touch gesture detection.

Prerequisites

Before we start, make sure you have:

MoonBit toolchain — install the moon CLI from moonbitlang.com/download
Android SDK + NDK — the easiest way is to install Android Studio, which bundles both. Make sure NDK is installed (Android Studio > Settings > SDK Manager > SDK Tools > NDK)
An Android device (or emulator) with USB debugging enabled. If you installed Android Studio with the recommended settings, it comes with an emulator ready to use.
ADB on your PATH (comes with Android SDK platform-tools) — only needed if you prefer building and deploying from the command line instead of Android Studio

Then install the scaffolding tool:

moon install tonyfettes/create-moonbit-raylib-android-app

This gives you the create-moonbit-raylib-android-app command, which generates a complete project ready to build.

Scaffold a New Project

Run the scaffolding tool to create a new project:

create-moonbit-raylib-android-app MyFlappyBird

This generates a complete Android project:

MyFlappyBird/
├── gradlew                          # Gradle build wrapper
├── settings.gradle.kts
├── app/
│   ├── build.gradle.kts             # Android build config (NDK, ABI targets)
│   ├── src/main/
│   │   ├── AndroidManifest.xml      # App manifest (NativeActivity)
│   │   ├── java/.../MainActivity.kt # Thin Kotlin entry point
│   │   ├── moonbit/                 # YOUR GAME CODE LIVES HERE
│   │   │   ├── main.mbt            # Starter game
│   │   │   ├── moon.mod.json       # MoonBit module config
│   │   │   └── moon.pkg            # Package declaration
│   │   └── cpp/
│   │       └── CMakeLists.txt       # Build pipeline glue
│   └── ...
└── gradle/

You can also open the project in Android Studio (click Open from the welcome screen). Switch to Project view to see the moonbit/ folder where your game code lives.

The scaffolding already configures the Raylib dependency in moon.mod.json and imports it in moon.pkg — you don't need to touch either file. The generated main.mbt is a hello world that displays centered text.

Build and Deploy

Building the project compiles your MoonBit code to C, then uses the Android NDK to compile everything into a native shared library packaged into an APK.

cd MyFlappyBird
./gradlew assembleDebug --no-daemon

The first build takes a few minutes (it compiles Raylib from source). Subsequent builds are much faster. If you opened the project in Android Studio, you can build and run in one step — select your device or emulator from the toolbar and click the Run button (green play triangle).

Or from the command line, install and launch on your device:

adb install -r app/build/outputs/apk/debug/app-debug.apk
adb shell am start -n com.example.myflappybird/com.example.myflappybird.MainActivity

Either way, you should see "Hello, World!" displayed on screen.

How It Works

When you run the build, the MoonBit toolchain first compiles your .mbt source into C code. The Android NDK then cross-compiles that C code — along with Raylib — into a native .so shared library.

At runtime, Kotlin's MainActivity launches NativeActivity, which loads the .so and hands control to your MoonBit game code linked with Raylib.

Make It Your Own: Flappy Bird

Every game follows the same core loop: initialize (create window, set up state), loop (update state from input, draw everything), cleanup (close window). Let's build a complete Flappy Bird clone. Replace app/src/main/moonbit/main.mbt with the code below — we'll go through it piece by piece.

Data Model

Three structs hold the entire game state:

///|
priv struct Bird {
  mut y : Float
  mut velocity : Float
}

///|
priv struct Pipe {
  mut x : Float
  mut gap_y : Float
  mut scored : Bool
}

///|
priv struct Game {
  sw : Float
  sh : Float
  bird_x : Float
  bird : Bird
  bird_radius : Float
  gravity : Float
  jump_force : Float
  pipes : Array[Pipe]
  pipe_width : Float
  gap_size : Float
  pipe_speed : Float
  pipe_spacing : Float
  mut score : Int
  mut game_over : Bool
}

Bird holds dynamic state (position and velocity). Pipe tracks each obstacle's position, gap center, and whether it's been scored. Constants like bird_x and bird_radius live in Game. All sizes derive from screen dimensions (sw, sh) so the game scales to any device.

Entity Behaviors

Each entity gets methods for its core behaviors. The fn Bird::method(self : Bird, ...) syntax lets us call these as game.bird.method(...) later.

Bird can reset, update its physics, and draw itself. Bird::update returns true if the bird hits the ceiling or floor:

///|
fn Bird::reset(self : Bird, sh : Float) -> Unit {
  self.y = sh / 2.0
  self.velocity = 0.0
}

///|
fn Bird::update(
  self : Bird,
  gravity : Float,
  radius : Float,
  sh : Float,
  dt : Float,
) -> Bool {
  self.velocity += gravity * dt
  self.y += self.velocity * dt
  // Hit ceiling or floor?
  self.y < radius || self.y > sh - radius
}

///|
fn Bird::draw(self : Bird, x : Float, radius : Float) -> Unit {
  @raylib.draw_circle_v(
    @raylib.Vector2::new(x, self.y),
    radius,
    @raylib.yellow,
  )
}

Multiplying by dt (seconds since last frame) makes the physics frame-rate independent.

Pipe can reset to a new position, draw its top and bottom rectangles, and check for collision with the bird:

///|
fn Pipe::reset(self : Pipe, x : Float, game : Game) -> Unit {
  self.x = x
  self.gap_y = random_gap_y(game)
  self.scored = false
}

///|
fn Pipe::draw(self : Pipe, width : Float, gap_size : Float) -> Unit {
  let px = self.x.to_int()
  let pw = width.to_int()
  let gap_top = (self.gap_y - gap_size / 2.0).to_int()
  let gap_bottom = (self.gap_y + gap_size / 2.0).to_int()
  @raylib.draw_rectangle(px, 0, pw, gap_top, @raylib.darkgreen)
  @raylib.draw_rectangle(
    px,
    gap_bottom,
    pw,
    @raylib.get_screen_height() - gap_bottom,
    @raylib.darkgreen,
  )
}

///|
fn Pipe::collides_with(
  self : Pipe,
  bird_x : Float,
  bird_y : Float,
  bird_radius : Float,
  pipe_width : Float,
  gap_size : Float,
) -> Bool {
  // Horizontal overlap and outside the gap = hit
  bird_x + bird_radius > self.x &&
  bird_x - bird_radius < self.x + pipe_width &&
  (bird_y - bird_radius < self.gap_y - gap_size / 2.0 ||
  bird_y + bird_radius > self.gap_y + gap_size / 2.0)
}

We also need a helper to generate random gap positions within safe bounds:

///|
fn random_gap_y(game : Game) -> Float {
  Float::from_int(
    @raylib.get_random_value(
      (game.gap_size / 2.0 + 50.0).to_int(),
      (game.sh - game.gap_size / 2.0 - 50.0).to_int(),
    ),
  )
}

Game Logic

With entity behaviors defined, the top-level functions orchestrate them. reset initializes the bird and spaces pipes evenly off-screen to the right:

///|
fn reset(game : Game) -> Unit {
  game.bird.reset(game.sh)
  game.score = 0
  game.game_over = false
  for i in 0..<game.pipes.length() {
    game.pipes[i].reset(game.sw + Float::from_int(i) * game.pipe_spacing, game)
  }
}

update handles input, physics, pipe scrolling, collision, and scoring. is_gesture_detected(GestureTap) responds to both touchscreen taps and mouse clicks, so you can test on desktop too. When a pipe scrolls off the left edge, it wraps to the right with a new random gap — creating infinite scrolling with just 4 objects:

///|
fn update(game : Game, dt : Float) -> Unit {
  if game.game_over {
    if @raylib.is_gesture_detected(@raylib.GestureTap) {
      reset(game)
    }
    return
  }

  if @raylib.is_gesture_detected(@raylib.GestureTap) {
    game.bird.velocity = game.jump_force
  }

  // Bird physics; boundary hit = game over
  if game.bird.update(game.gravity, game.bird_radius, game.sh, dt) {
    game.game_over = true
  }

  // Move pipes, check collision and scoring
  for pipe in game.pipes {
    pipe.x -= game.pipe_speed * dt
    if pipe.x < -game.pipe_width {
      pipe.reset(
        pipe.x + Float::from_int(game.pipes.length()) * game.pipe_spacing,
        game,
      )
    }

    if pipe.collides_with(
      game.bird_x,
      game.bird.y,
      game.bird_radius,
      game.pipe_width,
      game.gap_size,
    ) {
      game.game_over = true
    }

    // Score when bird passes a pipe
    if not(pipe.scored) && pipe.x + game.pipe_width < game.bird_x {
      game.score += 1
      pipe.scored = true
    }
  }
}

draw renders everything each frame. All Raylib draw calls must be between begin_drawing() and end_drawing(). Pipes are drawn before the bird so they render behind it. draw_centered_text is a small helper since we center text in three places ("\{game.score}" is MoonBit's string interpolation):

///|
fn draw_centered_text(
  text : String,
  y : Int,
  size : Int,
  color : @raylib.Color,
) -> Unit {
  @raylib.draw_text(
    text,
    (@raylib.get_screen_width() - @raylib.measure_text(text, size)) / 2,
    y,
    size,
    color,
  )
}

///|
fn draw(game : Game) -> Unit {
  @raylib.begin_drawing()
  @raylib.clear_background(@raylib.skyblue)
  for pipe in game.pipes {
    pipe.draw(game.pipe_width, game.gap_size)
  }
  game.bird.draw(game.bird_x, game.bird_radius)
  draw_centered_text(
    "\{game.score}", (game.sh * 0.05).to_int(),
    (game.sh / 10.0).to_int(), @raylib.white,
  )
  if game.game_over {
    let over_size = (game.sh / 12.0).to_int()
    draw_centered_text(
      "GAME OVER", (@raylib.get_screen_height() - over_size) / 2,
      over_size, @raylib.red,
    )
    draw_centered_text(
      "Tap to restart", @raylib.get_screen_height() / 2 + over_size / 2 + 10,
      (game.sh / 25.0).to_int(), @raylib.gray,
    )
  }
  @raylib.end_drawing()
}

Main

main ties everything together. init_window(0, 0, ...) makes the window fill the screen. The game loop is three lines: get delta time, update, draw:

///|
fn main {
  @raylib.init_window(0, 0, "Flappy Bird")
  @raylib.set_target_fps(60)
  @raylib.set_exit_key(0)
  let sw = Float::from_int(@raylib.get_screen_width())
  let sh = Float::from_int(@raylib.get_screen_height())
  let pipe_count = 4

  let game : Game = {
    sw,
    sh,
    bird_x: sw * 0.2,
    bird: { y: 0.0, velocity: 0.0 },
    bird_radius: sh / 25.0,
    gravity: sh * 1.5,
    jump_force: sh * -0.65,
    pipe_width: sh / 8.0,
    gap_size: sh / 4.0,
    pipe_speed: sw / 6.0,
    pipe_spacing: sw / 3.0,
    pipes: Array::makei(pipe_count, fn(_) {
      { x: 0.0, gap_y: 0.0, scored: false }
    }),
    score: 0,
    game_over: false,
  }
  reset(game)

  while not(@raylib.window_should_close()) {
    let dt = @raylib.get_frame_time()
    update(game, dt)
    draw(game)
  }
  @raylib.close_window()
}

Build and deploy to see the complete game:

./gradlew assembleDebug --no-daemon
adb install -r app/build/outputs/apk/debug/app-debug.apk

Where to Go Next

This tutorial covered the basics, but MoonBit + Raylib can handle much more complex games. Here are some directions to explore:

Raylib binding — the tonyfettes/raylib package provides MoonBit bindings for Raylib, covering shapes, textures, audio, 3D models, shaders, and more.
Selene — an experimental game engine built in MoonBit with both WebGPU and Raylib backends, designed for building web and native games.
MoonBit documentation — learn more about the language at docs.moonbitlang.com.

All the code in these examples was generated by AI, even including the Raylib bindings themselves. In a broader experiment, we used AI agents' subagent mechanism to parallelize game production, and this "factory" approach produced over 150 games across desktop, Web, and Android, with 100% AI-generated code and zero crashes. See the examples/ folder under tonyfettes/raylib for more on this.

The combination of MoonBit's native compilation, Raylib's simplicity, and the scaffolding tool's one-command setup makes this one of the most straightforward ways to build native Android games from scratch. No engine. No runtime. Just code.

Introducing MoonBit package manager: mooncakes.io

MoonBit — Thu, 22 Feb 2024 08:31:57 +0000

Today, we are thrilled to announce that mooncakes.io (the package management and sharing platform for MoonBit) has been officially launched! Alongside it, we're also introducing Moondoc, which serves as a crucial tool for documenting the various packages and libraries within mooncakes.io, ensuring that developers can easily understand and utilize the vast array of resources available.

The greatest value of MoonBit lies in its ecosystem. The earlier and more people get involved, the more we can develop the MoonBit platform and share its growth together. Although it is still at a very early stage and there is still a long way to go, we are eager to share it with everyone right now!

Next, let's dive deeper into mooncakes.io.

mooncakes.io: where the MoonBit community share

mooncakes.io is a centralized MoonBit package management platform. Here, users can easily upload, share, use, and explore various MoonBit modules. To facilitate this seamless interaction, MoonBit's build systemmoon, has integrated commands for interacting with mooncakes.io, eliminating the complexities of manual dependency downloads and configurations. Unlike other package managers, MoonBit's dependency resolution employs a minimal version selection algorithm similar to Go's, ensuring precise dependency builds without unnecessary upgrades, thus guaranteeing a stable and reproducible development environment.

mooncakes.io hosts all the MoonBit modules published by users, which can also be referred to as "mooncakes." The content published to mooncakes.io is modular, with each module potentially containing multiple packages. Each user on mooncakes.io has their own independent namespace, with the naming format for uploaded modules being <username>/<package_name>. The module versions released on mooncakes.io are defined according to Semantic Versioning 2.0.0, and MoonBit will resolve specific versions based on compatibility.

Moreover, mooncakes.io also serves as a documentation hosting platform. Once a user successfully publishes a module, mooncakes.io will automatically generate a documentation page for that module. We hope that such a centralized platform can provide users with a simple and consistent user experience.

To further enhance the user experience, we also offer a toolchain deeply integrated with mooncakes.io.

Integrated Toolchain for mooncakes.io

1. MoonBit's build system, `moon`:

moon login: Log in to mooncakes.io.
moon register: Register account on mooncakes.io
moon publish: Release a package to mooncakes.io, adhering to Semantic Versioning 2.0.0 principles. Each new version must sequentially increase.
moon add: Add a dependency. It will trigger dependency resolution, module and version identification, followed by the download of necessary modules from mooncakes.io, and automatic moon.mod.json updates.
moon remove: Remove a dependency.
moon tree: List all dependencies in a tree structure.
moon update: Update the local index. The index records all package versions and their dependencies on mooncakes.io. The index file is managed using git, so after the first update is completed, subsequent moon update commands can perform incremental updates, which requires the git command in your environment.
moon install: Automatically install all dependencies listed in the deps field of moon.mod.json.

2. `moondoc` Documentation Generation Tool

moondoc serves as a command-line tool that collects documentation comments from MoonBit projects and generates documentation information. When generating documentation, moondoc not only analyzes type information in top-level declarations but also provides links to the corresponding type documentation.

Users can add documentation comments that start with /// in front of any top-level fn, let, enum, trait, etc. These comments follow the Markdown format, as shown below:

Once the documentation is seamlessly constructed on mooncakes.io, users have the convenience of navigating directly to detailed documentation. By simply clicking on a type within any top-level signature—for instance, the Stack type, denoted with an underscore in the self parameter—users are instantly redirected to the comprehensive documentation page for the Stack type, as illustrated below:

The Moon build system seamlessly incorporates commands for generating documentation locally via moon doc and for previewing this documentation with moon doc --serve.

This comprehensive framework facilitates all aspects of dependency management, module uploading, and the creation and preview of documentation, all achievable through the integrated capabilities of the Moon build system.

What’s Next?

Integration with MoonBit Tools

Building documentation should be as easy as building code. A key initiative moving forward is the integration of mooncakes.io with core MoonBit tools. This integration aims to enable developers to effortlessly document their code right from the start of a project.

If you want to learn more about how to use mooncakes.io, detailed instructions and resources can be found at this link: https://www.moonbitlang.com/docs/package-manage-tour

Get involved and make a difference together!

Your experience, feedback, and contributions are greatly encouraged!

Get started by trying out https://mooncakes.io
Get help with using mooncakes.io in the forum or discord
File a bug report for problems you find, or ideas for improvements

Questions?

The MoonBit forum are open for any inquiries regarding this post. We invite you to post your questions and join the conversation, helping us shape the future of MoonBit together.

Programming Practice | How to implement a Pratt Parser in MoonBit?

MoonBit — Wed, 24 Jan 2024 09:00:00 +0000

In the realm of programming, syntax analysis, commonly referred to as parsing, plays a pivotal role during the compilation process. The parser's primary responsibility is to transform a stream of tokens into an abstract syntax tree (AST).

In this article, we will introduce Pratt parsing, a renowned algorithm for parsing, often recognized as top-down operator precedence parsing, and we will demonstrate how to implement it using MoonBit.

Why Using Pratt Parser

Almost all programmers are familiar with infix expressions, including staunch Lisp/Forth programmers. At least, they are aware that the majority of the world writes arithmetic expressions in this way:

24 * (x + 4)

For compiler (or interpreter) writers, parsing such infix expressions is slightly more challenging than parsing the prefix expressions used in Lisp and the postfix expressions used in Forth. For instance, using a basic handwritten recursive descent parser requires multiple mutually recursive functions, and handling left recursion in the grammar for expression syntax can make the code less user-friendly, especially as the number of operators increases. Parser generator tools also do not offer a very satisfactory solution in this regard. Take a BNF example of a simple addition and multiplication expression:

Expr ::=
    Factor
    | Expr '+' Factor
Factor ::=
    Atom
    | Factor '*' Atom
Atom ::=
    'number'
    | '(' Expr ')'

This is definitely not very intuitive, and one might even need to spend time revisiting formal language courses taken in university. In some languages like Haskell, which supports custom infix operators, solving this with a parser generator tool is almost impractical.

In such situations, the Pratt parser emerges as an effective solution for the complexities associated with parsing infix expressions. Its design is not only adept at handling these challenges but also offers remarkable versatility. It also allows for the straightforward integration of new operators, all without the need to modify existing source code. Esteemed in the field of compiler construction, the Pratt parser is recommended for use in conjunction with recursive descent parsers in the renowned book "Crafting Interpreters". Additionally, it is used in the Rust-analyzer project.

Binding Power in Pratt Parser

In the Pratt parser, the concept used to describe associativity and precedence is called "binding power." For each infix operator, its binding power consists of a pair of integers - one for the left and one for the right. This is illustrated below:

expr:   A     +     B     *     C
power:     3     3     5     5

And its function aligns perfectly with its name – the larger the number, the higher the precedence it has in grabbing a particular operand (in this example, A, B, C are operands).

The above example illustrates operators with different precedence levels, and the associativity of the same operator is represented by a pair of binding powers, one larger and one smaller.

expr:   A     +     B     +     C
power:     1     2     1     2

In this particular instance, as the parser encounters B, the expression undergoes a transformation due to its stronger left binding power, resulting in the following configuration:

expr:   (A + B)     +     C
power:           1     2

Next, let's delve into the practical application of Pratt parser and examine how it effectively employs this concept during execution.

Overview and Preliminary Preparation

The general framework of the Pratt parser is roughly as follows:

fn parseExpr(self : Tokens, min_bp : Int) -> Result[SExpr, String] {
    ......

    while true {
        .....
        parseExpr()
    }
}

From the above text, it can be seen that it is implemented using a combination of recursions and loops. This actually corresponds to two modes:

Always have the leftmost expression at the innermost level, i.e., "1 + 2 + 3" = "(1 + 2) + 3", and this can be parsed using loops.
Always have the rightmost expression at the innermost level, i.e., "1 + 2 + 3" = "1 + (2 + 3)", and this can be parsed using recursion.

min_bp is a parameter representing the binding power of an operator on the left that has not been parsed yet.

Since various errors may occur during this process, the return type of parseExpr is Result[SExpr, String].

However, before starting to write the parser, we also need to tokenize the string to obtain a simple token stream.

enum Token {
  Operand(String)
  Operator(String)
  Eof
} derive(Debug, Show, Eq)

struct Tokens {
  mut tokens : List[Token]
}

This token stream requires three methods: peek(), next(), and eat().

The peek() method retrieves the first token in the token stream without altering the state. In other words, it is side-effect-free; it merely takes a peek at the content to be processed. For an empty token stream, it returns Eof.

fn peek(self : Tokens) -> Token {
  match self.tokens {
    Cons(t, _) => t
    Nil => Eof
  }
}

next() consumes a token based on peek().

fn next(self : Tokens) -> Token {
  match self.tokens {
    Cons(t, ts) => {
      self.tokens = ts
      return t
    }
    Nil => Eof
  }
}

Our goal is to take in a token stream and output a prefix expression without considering precedence.

enum SExpr {
  Atom(String)
  Cons(String, Array[SExpr])
}

Finally, we need a function to calculate the binding power of operators, which can be implemented using a simple matchstatement. In practical implementation, to facilitate the addition of new operators, some key-value pair container should be used.

fn infix_binding_power(op : String) -> Result[(Int, Int), String] {
  match op {
    "+" => Ok((1, 2))
    "-" => Ok((1, 2))
    "/" => Ok((3, 4))
    "*" => Ok((3, 4))
    _ => Err("infix_binding_power(): bad op \(op)")
  }
}

Parser Implementation

The initial steps are straightforward. First, take out the first token and assign it to the variable lhs (short for left hand side, representing the left-hand side parameter).

If it is an operand, store it.
If it is a parenthesis (parentheses are also treated as an operator, but they are handled specially), recursively parse the first expression, then consume a pair of parentheses. The ? here is a new error-handling syntax introduced by MoonBit. If the preceding expression is Err(), the current function will terminate immediately, considering this Err() as the return value.
Any other results indicate a parsing issue, throw an error. Here, wrap an error string using Err().

let mut lhs : Result[SExpr, String] = match self.next() {
  Operand(s) => Ok(Atom(s))
  Operator("(") => {
    let expr = parseExpr(self, 0)?
    self.eat(Operator(")"))
    Ok(expr)
  }
  t => Err("bad token \(t)")
}

Next, let's take a look at the first operator:

If the result is Eof at this point, it doesn't necessarily mean failure. An operand can also be considered a complete expression, so we can exit the loop.
If the result is an operator, return it normally.
Any other result indicates an error.

  while true {
    let op : Result[String, String] = match self.peek() {
      Eof => { break }
      Operator(op) => Ok(op)
      t => Err("bad token \(t)")
    }
    let op = op?
    ......

Next, we need to determine which operator lhs belongs to. Here, we use the min_bp parameter, which represents the binding power of the nearest unfinished operator on the left. Its initial value is 0 (indicating no operator is competing for the first operand on the left). However, before that, we need to make a decision: is the operator a parenthesis? If it is, it means we are parsing an expression inside parentheses, and we should exit the loop directly. This is one of the reasons for using the peek method because we cannot determine whether to consume the operator here.

After calculating the binding power l_bp of the current operator op, we first compare it with min_bp:

If l_bp is less than min_bp, immediately break. This will return lhs to the upper level, where an operator is still waiting for the right-hand parameter.
Otherwise, use the next method to consume the current operator, and recursively call parseExpr to obtain the right-hand parameter. The second parameter is the right binding power of the current operator. After a successful parsing, assign the result to lhs and continue the loop.

    if op != ")" {
      let (l_bp, r_bp) = infix_binding_power(op)?
      if l_bp < min_bp {
        break
      }
      self.next()
      let l = lhs?
      let r = parseExpr(self, r_bp)?
      lhs = Ok(Cons(op, [l, r]))
      continue
    }
    break

At the end of the entire function, simply return lhs.

Usage Example: Stack-based Calculator

Reverse Polish Notation (RPN) is a mathematical notation introduced by Polish mathematician Jan Łukasiewicz in 1920. The distinctive feature of this notation is that operators are written after operands. Behind this somewhat peculiar appearance lies a close connection to the stack data structure. For example, the infix expression

17 + 13 * 3 corresponds to the RPN expression 17 13 3 * +. This can be implemented with a series of instructions.

Push(17)
Push(13)
Push(3)
Mul() // Take the top two elements from the stack, multiply them, and then put the result back on top of the stack.
Add() // As above, but replace multiplication with addition.

The conversion process from an arithmetic expression to a sequence of instructions is simple and direct.

fn compile(this : SExpr) -> List[Instruction] {
  // Can only handle arithmetic expressions.
  match this {
    Atom(s) => Cons(Push(string_to_int(s)), Nil)
    Cons("*", arr) => {
      append(append(compile(arr[0]), compile(arr[1])), Cons(Mul, Nil))
    }
    Cons("+", arr) => {
      append(append(compile(arr[0]), compile(arr[1])), Cons(Add, Nil))
    }
  }
}

For a detailed implementation of instruction interpretation, please see the complete code provided at the end of this article.

Conclusion

The Pratt parser is not only capable of handling infix operators but also versatile enough to cover postfix and prefix operators, as well as access operators like arr[i]. The complete code example provided here includes handling for prefix operators：try.moonbitlang.cn/#99b19baf

Reference

Matklad. (Apr 13, 2020) Simple but Powerful Pratt Parsing. https://matklad.github.io/2020/04/13/simple-but-powerful-pratt-parsing.html