Forem: John Samuel

Chromatic Automata: How Simple Rules Paint Surprising Worlds of Color

John Samuel — Sun, 05 Apr 2026 06:58:11 +0000

When we think about cellular automata, we often imagine black-and-white grids ticking forward in time, like digital snowstorms marching across the screen. But once we add color — palettes, gradients, and seasonal hues — these same simple rules start to resemble mountain ranges, woven textiles, or abstract paintings.

In this article, I explore how color transforms elementary cellular automata, starting from my earlier experiments with gradients and then moving into interactive, browser-based explorations.

From Two Tones to Color Gradients

In my previous piece, “Chromatic Evolution: Expanding the Color Palette of Cellular Automata,” I began with classic black‑and‑white rules and asked a simple question: what if each new row could have its own color gradient. By mapping cell states to smooth transitions between colors, the familiar triangular structures of rules like 50 or 30 suddenly looked like stylized mountain peaks and layered landscapes.

Even a fixed rule, when combined with evolving gradients, generates sequences of “paintings” rather than mere binary patterns.

Seasonal Palettes and Emergent Landscapes

Instead of sticking to arbitrary RGB picks, I started choosing palettes inspired by nature — for example, spring shades with distinct background and foreground colors. With five carefully separated colors, simple one‑dimensional rules produced scenes that evoke snow‑capped peaks, multi‑layered hills, or bands of vegetation.

Rule 57

Rule 150

Rule 225

Small tweaks to palette design — such as excluding the background from the foreground list — can make the main structures stand out more clearly while still preserving the underlying rule.

Exploring Colorful Automata in the Browser

To make these experiments accessible and reproducible, I built CellCosmos, a WebAssembly‑based explorer for elementary cellular automata. The core logic is written in a multilingual programming language and compiled to WASM, so it runs interactively in the browser while exposing parameters like rule, palette, and initial conditions.

Live tool: https://multilingualprogramming.github.io/cellcosmos/

With CellCosmos, you can:

Select any of the 256 elementary rules and instantly see how it behaves with different color schemes.
Experiment with multi‑stop gradients mapped to discrete states, turning a one‑dimensional rule into a rich chromatic texture.
Share configurations via encoded URLs, making it easy to revisit or remix particularly striking patterns.

Why Simple Rules Make Such Rich Colors

What makes all of this so fascinating is that none of the underlying rules change: the automata remain local, deterministic update systems on a line of cells. All the perceived complexity comes from how we choose to encode states as colors, how we separate background and foreground, and how gradients evolve across rows.

In other words, color acts as an interpretable lens on dynamics we already have, revealing mountains, waves, and tapestries that were always latent in the bit patterns.

I Built a Cellular Automata Explorer in WebAssembly — Here Are 21 Visual Experiments

John Samuel — Sat, 21 Mar 2026 21:14:40 +0000

The project

Over 21 days in May 2025, I used cellular automata as a daily sketchbook: one tool, one new constraint, one visual experiment per day. The result is CellCosmos — a browser-based elementary cellular automata explorer.

The twist: the core automaton logic is written in French-syntax source code using a multilingual programming language I've been building. That French source is compiled to WebAssembly (WASM) and runs at near-native speed in the browser.

🔗 Live tool: multilingualprogramming.github.io/cellcosmos
📦 Source (GPL-3.0): github.com/multilingualprogramming/cellcosmos

How it works technically

A cellular automaton starts with a finite grid of cells. Each cell holds a discrete state (in CellCosmos, small integers representing phases or ages). At each time step, every cell updates simultaneously based on a lookup at a small local neighborhood.

For a 1D elementary CA (the Wolfram model):

Each cell looks at itself and its two immediate neighbors → 3 cells → 8 possible binary patterns → 256 possible rules (Rule 0 through Rule 255)

For 2D automata, the neighborhood is the 4 orthogonal neighbors (von Neumann) or 8 surrounding cells including diagonals (Moore).

The build pipeline

The deployment is fully automated via GitHub Actions:

French-syntax source is compiled to WAT/WASM
The expected WASM exports are verified
The public/ directory is published to GitHub Pages as a static site — no server required

Parameters exposed in the tool

Parameter	Options
Rule selector	0–255, slider + named presets (Rule 30, 90, 110, 150, 184…)
Canvas shape	Rectangle, Circle, Ellipse, Triangle
Initial state	Centre seed or random distribution
Color	Background + multi-stop gradient mapped to cell states
Boundary	Hard edge or toroidal wrapping
Probability	0.0–1.0 stochastic transition strength
Direction	LTR or RTL rule application

Every configuration can be downloaded as a PNG or shared via a URL that encodes the full parameter state.

The 21 experiments

Breathing Life into Cellular Automata with Color

What I took away

Across these 21 posts, a few themes kept surfacing. Color is not decoration — it is a lens; the same rule under different palettes reads as geological strata, organic growth, digital glitch, or abstract painting. Space matters: moving the origin, wrapping the boundary, or changing the canvas shape transforms the composition even when the underlying dynamics are identical. Layering rules creates emergent complexity at the boundaries between regimes. And probability bridges the gap between crisp mathematical automata and the textures we recognize from nature.

The unifying thread: cellular automata are endlessly configurable once you treat them as a medium for visual exploration rather than only as objects of theoretical study. Every parameter — rule, palette, seed, boundary, shape, direction, probability — is a creative control.

The 21 days are over, but the exploration continues.

Try it yourself

Live tool: multilingualprogramming.github.io/cellcosmos
Source code (GPL-3.0): github.com/multilingualprogramming/cellcosmos
Multilingual programming project: github.com/multilingualprogramming

The "Copy link" button in the tool encodes the full parameter state into a shareable URL — rule, palette, canvas shape, seed position, probability, direction — so any configuration can be bookmarked or sent to someone else.

A Strange Permutation Substring Sequence: Introducing OEIS A359012

John Samuel — Fri, 13 Mar 2026 21:53:42 +0000

I’ve been exploring a new integer sequence on the OEIS, A359012, and turned it into a small experiment in “data‑driven number theory”. This post briefly introduces the sequence and shares links to the live dataset and code.

What is A359012?

A359012 tracks integers (k) that reappear inside permutation numbers (xPy) when (k) is formed by concatenating the digits of (x) and (y).

More concretely:

Take natural numbers (x) and (y).
Form (k) by writing the digits of (x) followed by the digits of (y).
Compute (xPy), the number of permutations of (x) objects taken (y) at a time.
If the decimal expansion of (xPy) contains (k) as a contiguous substring, then (k) belongs to A359012.

The first few terms (with one witness each) look like this:

k	x	y	xPy (permutations)
318	31	8	318073392000
557	55	7	1022755734000
692	69	2	4692
729	72	9	30885807297945600
2226	222	6	111822261510960

In each case, (k) appears as a substring of the decimal representation of (xPy).

A few empirical facts

Using a brute‑force generator up to (k < 10^6), the current dataset looks like this:

712 terms below 997 398.
Term lengths are heavily concentrated at 6 digits (565 out of 712 terms).
708 of 712 witnesses end in zero.
Only 4 palindromes appear so far: 9999, 29092, 343343, 805508.
The largest gap between consecutive terms is 26 763.

So A359012 is quite sparse, with strong biases in how its terms are embedded inside permutation values.

Building a Fractal Explorer to Test‑Drive My Homegrown Language

John Samuel — Sun, 08 Mar 2026 11:37:50 +0000

I’ve been building a small programming language and needed a project that was visual, demanding, and unforgiving about performance. Fractals turned out to be the perfect testbed: they’re embarrassingly parallel, heavy on floating‑point work, and any bug shows up immediately as a glitch on the screen.

In this post I’ll walk through how I wired a Fractal explorer in the browser using:

A homegrown language as the “authoring layer”
WebAssembly as the execution target
A minimal JavaScript shell for input and rendering

Why Fractals Make Great Language Benchmarks

From a distance, a fractal is just an image. From the runtime’s point of view, it’s a brutal little benchmark:

Millions of pixels, same loop shape, different data
Lots of floating‑point operations
Clear performance feedback: do users see results in milliseconds or seconds?

That combination makes fractals a nice stress test for:

Code generation quality (are we emitting tight loops?)
Numeric semantics (are we handling edge cases and precision consistently?)
Runtime model (do we block the UI thread, do we stream, can we refine progressively?)

Unlike a synthetic benchmark, you also get something beautiful at the end, which keeps motivation high.

Architecture: Language → WASM → Canvas

The overall architecture looks like this:

Write fractal logic in my language
Compile to WebAssembly.
Call the exported functions from JavaScript.
Stream results into an ImageData buffer on a <canvas>.

In more detail:

Language layer

Describes the per‑pixel computation: given coordinates and parameters, return an “escape value” that we’ll later map to color.
WebAssembly module

Exposes functions like:
- render_region(centerX, centerY, scale, width, height, maxIterations)
- Writes raw iteration counts into a linear memory buffer.
JavaScript shell
- Handles input (mouse, touch, wheel).
- Translates viewport changes into calls to render_region.
- Maps iteration counts → RGBA and blits to the canvas.

The nice thing about this layering: I can iterate on the language and the fractal formulas without touching the UI.

Authoring Fractals in a Custom Language

My language’s job here is: “describe what one pixel should do.” The core concept is a pure‑ish function that takes a coordinate and some parameters and returns a scalar:

Input: coordinate in the complex plane, global parameters (max iterations, escape radius, etc.).
Output: a number representing how “quickly” the point escapes or stabilizes.

Conceptually, the code you’d write in a conventional language looks like this:

// PSEUDOCODE – the real syntax is my language
fn iterate(x, y, params) -> int {
  // map (x, y) to complex plane
  // apply small iterative rule until escape or max iterations
  // return how long it took
}

In the language, I deliberately kept:

No classes, minimal state
Simple control flow
Explicit numeric types

Because the target is WebAssembly, avoiding hidden allocations and dynamic dispatch makes code generation much simpler.

WebAssembly: Trade‑offs and Lessons

Compiling to WebAssembly gives you:

Near‑native inner loops in the browser
A simple, linear memory model
Tooling that’s getting better every year

For this project, a few practical lessons:

Linear memory as a frame buffer I allocate a chunk of WASM memory as a raw u32 buffer. Each pixel gets one slot, which I fill with an integer “escape value.” JavaScript reads that buffer and maps it to colors.
Progressive refinement

Instead of rendering full quality in one go, I can render in passes: coarse grid first, then fill in gaps. This pattern gives users immediate feedback while the WASM loops keep working.
Responsiveness vs. throughput

You quickly learn to balance batch sizes. Large chunks make WASM efficient but can freeze the main thread; smaller chunks keep the UI snappy but add overhead. A simple “time budget per frame” works well enough.

If you want to go further, WebAssembly threads and SharedArrayBuffer open the door to true multi‑core rendering, but I kept this explorer single‑threaded to focus on the language itself.

The JavaScript Shell: Minimal but Important

JavaScript is the glue layer:

Sets up the <canvas> and a 2D context.
Manages the viewport (center, zoom).
Handles user input (drag, wheel, touch gestures).
Calls into WASM with the current viewport and reads back the buffer. A typical render cycle looks like:

User pans or zooms.
JS updates centerX, centerY, scale.
JS calls render_region on the WASM module.
WASM fills its output buffer with iteration counts.
JS maps those values to colors and updates ImageData.

This separation keeps the UI code tiny and lets the language + WASM do the heavy lifting.

Using Fractals as a Language Design Tool

Beyond having a cool demo, fractals turned out to be surprisingly useful for language design:

Semantics become visible

Off‑by‑one errors, numeric issues, or small semantic changes show up as visible artifacts. Great for debugging semantics and codegen.
Performance work is rewarding

Tightening a loop or changing a data layout translates directly into smoother zooms or higher iteration counts.
New features can be validated interactively

Adding a new numeric type, a control‑flow construct, or a standard library function can be exercised immediately by writing a new fractal “kernel” and seeing if it behaves.

It’s an ongoing feedback loop: improvements in the language make the explorer better, and new ideas from the explorer push the language forward.

Inside the Multilingual Playground: How the Browser, WASM Runtime, and Language Packs Fit Together

John Samuel — Sat, 28 Feb 2026 09:08:11 +0000

In a recent article, I explored how a human-language-first programming language can move from multilingual syntax to multilingual runtimes using WebAssembly. This post goes a level deeper and opens the hood on the browser playground that makes this possible.

If you have the playground open while reading, you can map each section here to something you can actually click, run, or modify.

The three layers of the playground

At a high level, the playground is three things working together:

Browser UI

A simple HTML/CSS/JavaScript interface with:
- A code editor
- A language selector (English, French, Spanish, …)
- A “Run” button
- Panels for program output and intermediate representations
WASM runtime

The multilingual interpreter, compiled to WebAssembly, plus a few helper pieces that make it easy to call from JavaScript. The interpreter does the heavy lifting: lexing, parsing, building the AST, and evaluating the program.
Language packs

Data that describes how each human language maps to the shared semantic core: keywords, operators, sometimes punctuation, and eventually error messages. Each pack is configuration, not a fork of the runtime, which is key to keeping the system maintainable.

You can think of it as: HTML talks to JS, JS talks to WASM, WASM talks to your code — and language packs change only the “accent”, not the meaning.

From source code to execution in the browser

When you write a program in the playground and hit “Run”, the flow is roughly:

Collect source and language choice

The UI grabs the text from the editor and the selected human language (for example, fr or en).
Call into the WASM module

JavaScript passes { source, language_id } into an exported WASM function via WebAssembly.instantiate bindings. Internally, the WASM module sees raw bytes and a language identifier, not “French” or “English” in any special way.
Lexing and parsing with language packs

Inside the WASM runtime, the lexer and parser look up the right keyword mapping for the chosen language pack. si, wenn, and if can all map to the same conditional AST node, regardless of the surface language.
Build the unified AST

The parser produces a single, language-agnostic AST. From this point on, the runtime is completely indifferent to which human language you wrote in.
Evaluate and send results back

The interpreter evaluates the AST, captures outputs and errors, and sends structured results back across the JS/WASM boundary. The browser then renders them in the output panel.

All of this happens inside a sandboxed environment in your browser, which is why learners only need a URL to experiment.

How language packs plug into the core

The language packs are what make the playground multilingual instead of just another monolingual WebAssembly demo.

A language pack typically contains things like:

Keyword mappings: if, else, while, etc. in a given language mapped to internal tokens or constructors
Logical operator names (and, or, not)
Literal conventions if they differ (for example, decimal separator)
Metadata like language name and code

In practice, the runtime does something conceptually like this:

Look up language_id in a registry of packs
Build lexer/parser tables using that pack’s tokens
Produce the same internal AST no matter which pack you used

Because the packs are configuration, adding a language is “just” adding some new lines and wiring it into the registry rather than forking the interpreter. That design is what makes it realistic to experiment with 10+ human languages without drowning in maintenance.

A nice side effect: the playground can show you the same program rendered in different surface syntaxes while keeping the underlying semantics identical.

Error handling and diagnostics today (and tomorrow)

Error handling is where multilingual runtimes get interesting.

Right now, the playground leans on a simple but powerful separation:

The core interpreter produces language-agnostic error codes and structures.
The browser UI is responsible for displaying those errors to the user in a friendly way.

That design opens the door to more advanced diagnostics:

Localized error message catalogs keyed by error code
The ability to show errors in the same human language as the source
Potentially toggling the language of diagnostics without rerunning the program

For example, the same parse error could be rendered in French and then in English just by swapping the message catalog, while the underlying error object stays the same. A WASM-based playground is a convenient place to prototype this because everything is already running in the browser and can react in real time.

Deployment and extensibility

From a deployment perspective, the playground is just static assets:

HTML and CSS for the UI
JavaScript glue code
The compiled WASM binary
JSON or similar files for language packs

That makes it easy to host on GitHub Pages or a personal site, as in the current playground. Once the interpreter is compiled to WASM, the same core can also be reused in other contexts: online textbooks, documentation, or even IDE extensions via a WASI environment.

There are several natural directions to extend this setup:

More language packs, including scripts and writing systems that stretch assumptions about keywords and layout
Richer visualizations of the pipeline (for example, showing WAT or internal AST alongside your code)
Embeddable widgets where the multilingual runtime appears inside tutorials and interactive learning material

If you try the playground and experiment with new languages or ideas for diagnostics, I would love feedback and contributions in the repository.

From Multilingual Syntax to Multilingual Runtimes: Taking a Human-Language-First Language to the Web

John Samuel — Tue, 24 Feb 2026 18:25:51 +0000

In my previous post, I introduced multilingual, an experimental programming language where the same abstract syntax tree can be written in English, French, Spanish, and other human languages while preserving identical semantics. That work focused on the surface of the language: how we let people read and write code in the language they are most comfortable with, without changing what the program does.

In this follow-up, I want to go one step further and ask: what happens when you bring this idea to the Web and to WebAssembly (WASM)?

Can a single semantic core, expressed in multiple human languages, also have a single, portable runtime story?
How far can we push this idea before “multilingual” stops being just a toy language and starts looking like a serious experimentation platform for human-language–aware tooling?

To explore these questions, I’ve been experimenting with compiling the multilingual interpreter and tooling to WASM and exposing it through a browser playground.

Project repository: https://github.com/johnsamuelwrites/multilingual
Online playground: https://johnsamuel.info/multilingual/playground.html

Recap: One Semantic Core, Many Human Languages

The core idea of multilingual is simple to state but surprisingly rich to work with: you write code in different human languages, but it all maps to the same underlying AST and semantics.

In practice, that means:

There is a single, language-agnostic core language: control flow, expressions, and data structures live here.
Human languages appear as mappings from localized keywords and identifiers to that core: for example, if / si / si (English/French/Spanish) all map to the same conditional node.
The interpreter never “cares” whether your source was French or English; by the time it runs, it is operating on the unified AST.

This separation is what enables multilingual to be more than a localized syntax layer on top of an existing language: it is an experiment in treating human language as a first-class dimension of the programming environment itself.

Why WebAssembly Matters for a Multilingual Language

If you have a language whose goal is to welcome developers in multiple human languages, you want the runtime to be equally portable.

WebAssembly is particularly interesting in this context because it gives us:

A sandboxed, predictable execution model that runs in modern browsers and outside the browser in WASI environments.
A well-defined binary target for compilers and interpreters written in languages like C, C++, and Rust.
A path to reuse the same core, even if the surface syntax varies dramatically across human languages.

For an experimental language like multilingual, WASM offers two big advantages:

You can ship the whole interpreter and tooling directly into the browser, so learners only need a URL, not an installation guide.
You can treat the Web as a live laboratory to test multilingual error messages, editor integrations, and teaching scenarios.

In other words, if the goal is to make programming more approachable in more human languages, WASM lets us meet people where they already are: in the browser.

The Playground: A Multilingual Interpreter in Your Browser

The playground is the first concrete step in that direction: it loads the language core in the browser and lets you write and run programs in different human languages side by side.

Playground: https://johnsamuel.info/multilingual/playground.html

At a high level, the architecture looks like this:

The core interpreter is compiled to WebAssembly using a systems language toolchain.
The browser page handles text input, language selection, and UI in plain HTML/CSS/JavaScript.
When you run code, the UI sends your multilingual source to the WASM module, which parses it, builds the AST, and executes it.

This separation mirrors the language design:

The UI is responsible for dealing with the user’s language preferences, fonts, directionality, and input quirks.
The WASM module is responsible for understanding the core language and enforcing identical semantics regardless of human language.

Because the interpreter runs entirely in the browser, you also get some nice side-effects:

No server-side execution is required, which simplifies deployment.
You can experiment with new keyword mappings and language packs and immediately see their behavior.
The environment is inherently sandboxed, piggybacking on the browser’s security model.

Multilingual Error Messages and Diagnostics

Once you have a language that can be written in multiple human languages and a runtime that can be delivered as WASM, the next natural step is tooling.

In a traditional language, error messages are often an afterthought. In a multilingual language, they become central:

Syntax errors can be reported in the same human language as the source code.
Error hints can guide beginners using vocabulary that makes sense in their linguistic context.
In mixed-language codebases, you can imagine selectively switching diagnostic languages without changing the underlying program.

A WASM-based playground is a great place to prototype this because:

You can build a small, interactive REPL where users see errors in real time.
You can experiment with toggling error-message languages without reloading or recompiling.
You can embed teaching material directly in the browser, close to the diagnostics.

From an implementation standpoint, this suggests a clear design direction:

Keep error codes and structures language-agnostic in the core.
Maintain localized message catalogs and explanations in separate resources, possibly keyed by the same identifiers used for keywords.

Thinking Ahead: Multilingual Tooling, IDEs, and Beyond

WASM is not just a deployment target; it is a bridge between language runtimes and modern developer tools.

Once you have the multilingual core compiled to WASM, several possibilities open up:

Embeddable interpreters in online textbooks and tutorials, where each reader can choose their preferred human language.
Language-server–like functionality running in the browser, providing autocompletion and diagnostics for multilingual code.
Integration with “traditional” editors via a WASI runtime, so the same core can power both web and desktop experiences.

This also connects to broader work on multilingual programming and natural-language–friendly programming environments. The long-term question is not just “can we localize keywords?” but “what does a programming ecosystem look like when human language is no longer an afterthought?” stackoverflow

What’s Next?

A few directions I am exploring and would love feedback on:

Richer language packs: extending and experimenting with scripts and writing systems that challenge our assumptions about syntax.
More powerful WASM integrations: exploring how far we can push the browser-based environment (e.g., file-like APIs via WASI, richer visualization of program state).
Community-contributed mappings: making it easier for contributors to define and share mappings for their own languages via simple configuration files in the repository.

If you are interested in any of these ideas, want to try the language, or have thoughts on making programming more inclusive across human languages, you can:

Experiment in the playground: https://johnsamuel.info/multilingual/playground.html
Read the original post introducing the language: https://dev.to/jsamwrites/a-multilingual-programming-language-where-the-same-ast-runs-english-french-spanish-etc-23bd reddit
Browse or contribute to the source: https://github.com/johnsamuelwrites/multilingual

I would love to hear how you imagine using a human-language–first programming environment in your own work or teaching.

A multilingual programming language where the same AST runs English, French, Spanish, etc.

John Samuel — Sat, 21 Feb 2026 14:37:49 +0000

What if the only thing that changed between English and French code was the surface syntax, not the interpreter?

tl;dr

1. One tiny semantic core, many language-specific “frontends”.

2. Code written in French, English, etc. maps to the same AST and runtime.

3. You can swap surface languages without changing the underlying program.

Most programming languages quietly assume that you think in English.

Keywords, error messages, tutorials, library names – everything is shaped around one language, even when the underlying semantics are universal.

I’ve been experimenting with a different approach: keep a tiny, shared semantic core, and let the surface syntax (keywords, word order) adapt to the programmer’s natural language.

The result is an interpreter where the same AST can execute code written in French, English, Spanish, Arabic, Japanese, and more – without a translation step.

Repository: https://github.com/johnsamuelwrites/multilingual

Why separate surface syntax from the core?

When we teach or learn programming, we often say “syntax is just sugar, what really matters is semantics.”

But in practice, syntax is where beginners feel the most friction – especially if they’re also learning English at the same time.

The idea here is to pull that intuition to the extreme:

Keep one small semantic core (conditions, functions, variables, blocks, etc.).
Describe each human language as a thin “frontend” that maps its own keywords and patterns into that core.
Make these mappings explicit and inspectable, instead of hard-coding English everywhere.

This lets you ask questions like: what would this program look like if all the keywords were in French or Spanish? – while still running through the same interpreter pipeline.

How the interpreter is structured

How the interpreter is structured
At a high level, the interpreter is split into three layers:

Surface syntax layer – Knows about keywords and word order for a specific human language (e.g., if vs si, print vs afficher). It only parses and normalizes, it never executes.
Semantic core – A small, language‑agnostic core with expressions, statements, control flow, function calls, and environments. This is where the AST lives.
Runtime / execution engine – Walks the core AST and evaluates it. At this point, the runtime is completely blind to the human language you used.

Each surface syntax module is responsible for normalizing its input into the same core representation.

That’s where most of the interesting language-design questions arise.

A tiny example

Suppose you want to express a simple conditional and a loop.

In an English-shaped surface syntax, you might write something close to Python-like pseudocode:

if x > 0:
    print("positive")

In a French surface syntax, the structure is analogous but with French keywords (this is illustrative – see the repo for the real examples):

si x > 0:
    afficher("positif")

Both of these are parsed into the same core AST node: a conditional expression with a predicate and a block.

The runtime never needs to know whether the original keyword was if or si.

The same idea extends to loops, function definitions, and so on.

Another tiny example

Suppose you want to write a function that prints numbers from 1 to 3 if a flag is set.

English-shaped surface syntax

if enabled:
  for n in 1..3:
    print(n)

French-shaped surface syntax (illustrative)

si actif:
  pour n dans 1..3:
    afficher(n)

Both programs are parsed into the same core AST: a conditional node whose body contains a loop over a range and a call to a print function. The runtime never needs to know whether the original keyword was if or si.

Why this might be useful

This is still an experiment, but a few potential use cases are emerging:

Teaching in non-English contexts

Instructors can show code with keywords in the students’ own language, while still having a single, shared semantic model under the hood.
Research on multilingual PL design

It becomes easier to compare how different natural languages “want” to express the same control structures, and where word-order differences start to matter.
Accessibility and experimentation

People can prototype their own keyword sets or dialects without forking the whole interpreter, as long as they can map back to the core.

Open questions and limitations

There are plenty of hard questions I’m still exploring:

How far can you push word-order differences before the surface layer becomes too complex?
How do you keep each mapping semantics-preserving, and how do you test that rigorously?
Where do you draw the line between “just syntax” and constructs that really should live in the core language?

Right now, the project is deliberately small and experimental; the focus is on keeping the core minimal and making the mappings explicit, rather than covering every possible language feature.

How to try it, and how you can help

If this idea interests you, you can:

Check out the repo: https://github.com/johnsamuelwrites/multilingual
Run the examples and look at how the surface syntax modules map into the core.
Open issues or PRs with:
- new language mappings,
- critiques of the core design,
- ideas for better ways to specify and test the semantics.