Language compliance
pxx is one compiler with several language frontends, all lowering to a shared IR. Each frontend aims at a different fidelity target — some track a reference implementation closely, some are a deliberate subset, and one (BASIC) is a bespoke dialect with no reference at all. This page is the honest map of how close each one is.
| Language | Status | Fidelity target |
|---|---|---|
| Object Pascal | Supported* | FPC-compatible, plus the pxx dialect extensions |
| C | Supported* | C99 — GCC extensions out of scope (or deliberately limited) |
| Delphi | Partial | Delphi-compatible subset — limited |
| nilpy (Python-like) | Experimental | Python syntax only — the CPython library ecosystem is out of scope (pxx is a compiler, not a Python runtime) |
| BASIC | Experimental | None — a pxx bespoke BASIC, no compatibility target |
| Rust (& others) | Experimental | rustc — early; matures as the shared IR does |
| Zig | Experimental | Early, but promising — maps well onto the shared IR |
| C++ | Never | Will not be implemented — see below |
* The target is full support — open issues may still remain.
Object Pascal — the primary frontend
The Pascal frontend is the most complete: a tested Object Pascal surface (classes, generics, interfaces, exceptions, RTTI). A from-scratch implementation that targets FPC compatibility, tracking FPC behaviour for implemented features and adding pxx-specific extensions on top.
- FPC conformance — the FPC test suite run against the frontend, with live pass/skip numbers (under Status, with the other test results).
- pxx dialect — the supported surface, the extensions, and where it diverges on purpose.
- FPC compatibility notes in the documentation.
The compiler's own source
pxx compiles itself, and its own source is written in deliberately plain Pascal — not the full Object Pascal surface. Not out of necessity (FPC would happily compile Object Pascal): the fewer language features the compiler leans on, the fewer chances for a self-compilation bug, so self-hosting stays simpler and more reliable. A self-imposed floor, separate from what the Pascal frontend accepts for user code.
C — C99
The C frontend targets C99. GCC-specific extensions are out of scope, or supported only where a real-world corpus forces the issue; the goal is standard C behaviour, validated against a reference compiler as an oracle (e.g. a pxx-built zlib producing output byte-identical to a gcc-built zlib — behavioural parity, not identical machine code).
Delphi
Delphi compatibility is a limited subset — enough shared Object Pascal surface to compile common Delphi code, without chasing full Delphi/VCL parity.
nilpy — Python-like syntax
nilpy accepts a Python-like syntax and compiles it through the same IR. The compatibility target is the language surface, not the Python ecosystem: CPython's C-extension libraries and runtime are explicitly out of scope. pxx is a compiler — it borrows the syntax, not the world of pip.
BASIC — a bespoke dialect
The BASIC frontend has no compatibility target. It is a pxx bespoke BASIC: a small, self-consistent dialect that exists to exercise the frontend/IR boundary, not to match any historical BASIC.
Rust, Zig & other experimental frontends
Rust and Zig (and future frontends) are experimental. Zig in particular is early but promising — it maps cleanly onto pxx's model. They all lower to the same shared IR, so as that substrate matures — more IR ops, richer type model, more backends — bringing up an additional language gets progressively cheaper. Early today; on a curve that bends the right way.
C++ — deliberately never
C++ will not be implemented. Its grammar is huge and context-sensitive, and its real-world build model pulls in a heavyweight toolchain (headers, templates, name mangling, the preprocessor-and-modules tangle). The cost never justifies the payoff.