PolyGlot BASIC

PolyGlot BASIC

PolyGlot BASIC (PGB) is the super-compiler the whole ALB project has been walking toward: one source language in, and every programming language that was ever used — by anyone, anywhere, in any era — out. It is both a new compiler and the umbrella name for the polyglot direction itself: where albt, malbr, and malb are the early-access era's compilers, PGB is the finished, ready-to-use product — every backend completed and working, not in testing.

I coined the name about a month ago, and I have been working on it furiously ever since. The name is the claim: polyglot — one clean BASIC that compiles into every language modern machines, old machines, and dead machines ever ran.

The architecture mistake PGB exists to fix

PGB's design is a confession. Early in ALB I made a mistake: I jammed nearly everything into the AST walker and the lexer — the only thing I actually separated was the emitters. It worked, but it fought me every time the target list grew. A compiler that wants to reach hundreds of languages cannot be a monolith with emitters bolted on.

PGB separates everything:

• the lexer is its own unit
• the parser is its own unit
• the AST is its own unit
• every backend is its own unit
• every emitter is its own unit

One master compiler, clean seams at every layer — the structure a "super compiler" actually requires. The input stays deliberately boring: the same ALB dialect every other ALB compiler accepts, 100% backwards compatible with ALB and MALBR, with room to grow new syntax. The files get their own names — .pgb programs, .pgbi includes, .pgbproj projects — but the language underneath is the one this wiki already documents. In a more compromising design decision, | stays string concatenation and & is accepted as its alias, as in ALB.

Every language ever used — including the dead ones

The target list is the point: not "the languages currently fashionable," but every programming language ever used by companies or individuals, in any era, in any place — compiled languages, interpreted languages, and dead languages nobody maintains a compiler for anymore. COMTRAN, FLOW-MATIC, MAD, TRAC, JOVIAL, Coral 66, Autocode — the languages this wiki writes obituaries for are the languages PGB intends to keep runnable. Honest hedge, stated up front: there may be languages I cannot reasonably target in the end — but right now the project is a "stop when I discover it" situation, not a curated shortlist.

How does one developer build emitters for hundreds of languages? By way of AI — PGB uses AI assistance to expand the emitter library where the grind would otherwise make the goal unreachable. The ambition is human; the bulldozer is not.

The machines, too — not just the languages

Languages are half the problem; the other half is hardware. PGB emits for vintage machines directly — not through a vintage language's modern toolchain, but straight to the metal. The 8088 and 6502 emitters are nearly finished as of this writing, and much more is coming. Most backends emit assembly directly; where a target has no real assembler or no sane assembly mapping, the emitter drops lower still and emits machine code ops itself. The coverage goal spans every word width that ever shipped: 8-, 16-, 32-, 64-, and 128-bit — and down below eight bits to 4-bit and even 2-bit machines.

What it ships as

PGB is the finished product, and it is packaged like one: one self-contained .zip, every dependency bundled inside — on track to be nearly 10–15 GB when complete, because "batteries included" means all the batteries: every backend toolchain, every runtime, every target's own compiler where one is needed. Download it, unzip it, and the whole polyglot direction is there — no package manager archaeology, no version-locked dependency hunt.

The foundation it starts from

The ambition is huge but the base is real. PGB builds on the backend roster the ALB master compiler already routes today — and ships them completed and working, not in testing:

• native — albt: FASM, FASM16, C and the native targets
• retro — 6502/C64, 8088, NASM (win64)
• managed/script — TypeScript/JavaScript (web), .NET/C#, Java/FlatJVM, Python, Lua, MoonScript
• systems — Rust, Haskell, Odin, Ada
• curiosities — Brainfuck (ALBB), Godot
• plus the ENABLE* runtime blocks — ENABLEC, ENABLEADA, ENABLEASM, ENABLEPYTHON, ENABLEJAVA, ENABLECSHARP, ENABLETS — that let foreign-language modules live inside a host program

All of it is written 100% in SPARK Ada 2014 — the same discipline AdaLog was a rehearsal for. Fast, super-optimized, and honest about what it is: the beta period ends here.

The philosophy — why keep languages alive

The problem PGB solves is four things at once: portability, preservation, interoperability — and spite at language lock-in. Languages die when the last toolchain for them dies; machines die when the last language that could reach them dies. PGB is a bet that one clean syntax can keep both alive — that a dead language preserved only in a manual is a museum piece, but a dead language you can still compile into is still a language.

And the honest version of why hundreds of targets: I have severe ADHD, and I jump between many different subjects — that's how I am with everything. Most projects that jump like that die of it. A compiler whose entire purpose is reaching everything is the one project where the jumping is the job.

Where it sits

PGB is the successor product: ALB is the early-access era — the language proven, the backends discovered, the mistakes made. PolyGlot BASIC is what that era was for — the same language, the same syntax, the finished compiler that carries it everywhere a program has ever been able to run.

Check your understanding

• Is PGB a new compiler, an umbrella name, or both — and what dialect does it accept?
• What architecture mistake in ALB did PGB's design fix?
• What are the three PGB file extensions for?
• Which two vintage emitters are nearly finished?
• How does PGB propose to keep dead languages alive?
• What does the ~10–15 GB zip represent?