Ze: Designing One Interpreter for English, Tagalog, and Bisaya

Ze explores a question about the surface of programming: can equivalent programs use English, Tagalog, or Bisaya keywords while sharing one grammar and one runtime?

The current implementation is an interpreted language written in Go. Its .ze source files use indentation-based blocks, familiar values and control flow, and natural-language comparison phrases. Equivalent keyword families normalize into the same tokens and syntax tree.

The Ze project page includes the current Windows interpreter, VS Code extension, screenshots, and an example. This dedicated article describes the current implementation rather than treating earlier language experiments as an unchanged release.

Different Spellings, Shared Meaning

Bindings can use keyword families such as set, itakda, or ibutang; output can use show or ipakita. A source file can mix supported families without requiring a separate interpreter for each one.

The goal is semantic consistency. Changing the supported spelling of a binding keyword should not change how the value is stored or how a later condition is evaluated. The multilingual surface feeds common language operations.

That also defines the scope. Ze supports authored keyword aliases and grammar rules. It does not translate unrestricted natural-language descriptions into arbitrary programs. A sentence sounding understandable to a person is not enough to make it valid syntax.

For an approachable first exercise, take the age-check example from the documentation and change its keyword family. Then change the compared value and observe the result. The spelling change and the logical change should be distinguishable.

Normalization Belongs Near Tokenization

The lexer converts source characters into identifiers, literals, operators, punctuation, and language keywords. Multilingual equivalents can map to a common token kind before the parser constructs the program structure.

That avoids maintaining several nearly identical runtime implementations. The evaluator can execute a conditional operation without knowing whether the author introduced it through English, Tagalog, or Bisaya spelling.

Source location still matters. Normalizing a token should not erase the line or column needed to explain an error. A useful diagnostic needs to point back to the program the author actually wrote, including a supported phrase that was completed incorrectly.

The distinction becomes especially visible with natural-language comparisons. A phrase such as an at-least comparison has structural meaning; recognizing it must fit the grammar rather than rely on a general text replacement that can accidentally modify identifiers or strings.

Indentation Is Part of the Program

Indentation-based blocks make scope readable with less punctuation, but whitespace now participates in structure. A conditional body needs a consistent boundary so the parser can distinguish a nested statement from the next statement outside it.

That means malformed indentation is a language error to diagnose, not merely a visual inconsistency. The parser's syntax tree needs to represent blocks and control flow explicitly before evaluation.

Separating lexing, parsing, and evaluation helps keep these responsibilities clear. A malformed literal, an invalid block, and an operation on an unsuitable runtime value belong to different stages. Reporting all three as an unexplained execution failure would make the language harder to learn.

The Runtime Gives the Syntax Consequences

An interpreter needs a value model, environments for names, rules for evaluating expressions, and a way to execute statements in the intended order. The readable surface only becomes a language when those rules stay consistent across examples.

For a user, a small feedback loop matters: run a script, inspect its output or error, adjust it, and try again. The CLI can execute a source file, while invoking the interpreter without a file opens the REPL for smaller experiments.

The editor extension supplies highlighting, brackets, indentation, folding, and snippets. Those are useful supports, but the interpreter remains responsible for what the program actually means. Highlighted text alone is not a successful parse or a valid execution.

From a Script to a Modular Backend

Ze also includes an HTTP runtime and database tooling. The documented CRUD example uses a modular backend with a source entry and schema, and the CLI's serve/start commands provide an application-oriented workflow.

The current project uses a pure-Go SQLite driver and also includes MongoDB examples. Database configuration and the semantics of the chosen operation remain part of the application; multilingual syntax does not remove those requirements.

This is a different direction from asking every reader to learn a general compiler toolchain before seeing an endpoint work. The interpreter executes the application source through its own runtime. Ryft, by comparison, checks .rz programs and produces native services through generated Rust.

Both can expose HTTP behavior, but their build artifacts, deployment steps, and runtime boundaries should not be collapsed into one feature list.

Readability Needs More Than Keyword Translation

A translated keyword can make an entry point feel more familiar, but identifiers, errors, examples, editor behavior, and consistent semantics all affect readability. A language that accepts three equivalent forms but explains failures in an opaque way would still be difficult to use.

I would evaluate Ze with small equivalent programs and deliberately broken examples. Can a reader explain what changed when the spelling changes? Can they locate a malformed comparison or a block error? Can they distinguish a missing environment value from a syntax problem?

Those questions are more informative than claiming that multilingual syntax automatically improves learning. No learning-outcome study is asserted here; the project creates a concrete implementation that can be examined and tested.

Explore the Current Interpreter

The project downloads and guide provide the supplied Go-based interpreter and editor tooling. Start with a short local example, preserve its logic, and try another supported keyword family before adding more features.

For current automation and network primitives, read the Zy article. The earlier combined language write-up records the broader exploration, while these individual posts keep each current project's implementation and limitations visible.