On Mon, Jun 16, 2025, at 09:05, wheakerd wrote: > Dear PHP Internals, > > I am submitting this proposal for discussion regarding a potential future > direction for PHP: moving toward a CLI-only development model and introducing > an optional Ahead-of-Time (AOT) compilation infrastructure. > > While this may not fully align with PHP’s traditional interpreter-based > design, I believe it opens up valuable opportunities to modernize PHP's > runtime and improve performance, portability, and long-term maintainability.
We kinda already have this — to a degree. You can enable pre-loading and OPcache. In case you aren’t aware (I wasn’t just a year ago!) OPcache is quite advanced and does much of the same stuff a traditional compiler does: (transforms the source into an IR and can even run SSA on it — assuming I read the extension correctly, and I’m fairly confident in that). > ===== Current Development Landscape ===== > Contemporary PHP projects are already moving toward architecture patterns > that resemble compiled systems: > > - Frameworks define service containers, dependency graphs, and code > generation layers. > - Static analysis tools (Psalm, PHPStan) are integral to modern development. > - Code is often bootstrapped through CLI pipelines: for build, testing, > deployment, and even request simulation (`php artisan`, `bin/console`, etc.). > - Composer autoloading, annotation processors, and classmaps are precomputed. > - Web servers (e.g., Swoole, RoadRunner) are replacing FPM in > performance-critical applications, with CLI processes becoming long-lived > daemons. > > All of this reflects a growing shift: **PHP is increasingly behaving like a > static backend language**, except it still runs on a dynamic interpreter. > > This proposal attempts to provide native language support and compiler > infrastructure that aligns with these modern PHP usage patterns. I’m unsure why you’re asserting that compiled systems only use these architectural patterns? They’re patterns and thus can be used in JavaScript, or even Lisp, if you want to. It doesn’t mean the language has to be compiled to generate code (in fact, were it a compiled language, generating code would be nigh impossible during runtime). > > ===== Motivation ===== > PHP’s traditional runtime model (FPM or mod_php) is optimized for > short-lived, script-based execution. However, this limits PHP’s potential in: > > - Serverless or event-driven environments (high cold start cost). > - Embedded targets and containers with limited runtime support. > - Modular system design where PHP extensions must be written in C. > - Distributable binaries for CLI tools or desktop-style apps. > > PHP developers are often forced to work around these limitations using > complex workarounds (e.g., caching containers, annotation scans, custom > autoloaders, preload hacks). AOT compilation and CLI-first design can solve > these challenges directly, natively. I’m sorry; you’ve lost me here. How does "short-lived" execution fail in serverless or event-driven environments? Isn’t that the entire point? Serverless is basically a reinvention of CGI, which PHP excels at. However, the people who built these runtimes didn’t realise what they were reinventing to run long-lived applications and didn’t include PHP because "PHP is dying" for the last 20 years. This is a failure of the people who built the runtimes, not PHP’s execution model. It is a political issue, not a technical one. I primarily work with embedded PHP, there is even an ancient book about it (which is how I first got into php-src). Embedded PHP is where it is at if you ask me. It is a great language for it, especially because there is a lot of PHP talent out there quite used to dealing with "shared nothing", "stateless", "event driven" architecture. Then there is the fact that PHP extensions must be written in C. This is a false assertion. They may also be written in C++, or any language that can bind with C libraries (like Go, Zig, Rust, or even C#). Also, it is false that you can’t distribute CLI tools written in PHP. There is at least one project that lets you bundle your PHP project in a statically built, self-extracting executable. > ===== Proposal ===== > ### 1. Compiler Infrastructure (AOT Mode) > A new compiler pipeline would be introduced: > > - **Frontend**: Parse PHP source into AST (reusing current infrastructure). > - **IR Layer**: Transform AST into intermediate representation (IR). > - **Backend**: Compile IR into native binary via C transpilation or LLVM > backend. > > ### 2. Required Language Model Changes > To make PHP compilable in AOT mode, certain dynamic features must be > restricted or restructured. The following are required: > > #### a. **Static Code & Configuration** > - Dynamic constructs (e.g., `eval`, dynamic includes/classes/functions) are > disallowed. > - Project must provide static configuration file (`php.compiler.json`) for > classmap, entrypoint, environment constants, etc. > - No runtime-based code discovery or composition. > > #### b. **Unified Standard Library** > - Procedural global functions (e.g., `strlen`, `array_merge`) are > consolidated into base classes (e.g., `Str::len()`, `Arr::merge()`). > - Modules gain clearer boundaries and dependency injection support. > > #### c. **Environment Interfaces** > - Superglobals (`$_ENV`, `$_SERVER`, etc.) are abstracted via interfaces or > injectable system services. > > #### d. **Type System Enhancements** > - Strong use of `declare(strict_types=1)`, interfaces, final classes, and > property types. > - Optional compilation-time type enforcement and inference. > > #### e. **Compiler Extension Hooks** > - Developers or frameworks can hook into compilation stages (AST > transformation, IR passes) to generate optimized artifacts. > > ### 3. CLI-Only Development Focus > - CLI becomes the canonical platform for PHP execution and development. > - PHP-FPM and SAPI models remain available for backward compatibility but are > **not required** for future application delivery. > - Built-in CLI runners or Web adapters (e.g., `php serve`, Swoole adapters) > provide development/testing environments. > > ===== Expected Benefits ===== > - Native, standalone executables—no PHP interpreter dependency. > - Fast cold start (useful in serverless and event-driven environments). > - PHP extensions can be authored in PHP and compiled, removing the C barrier. > - Clean separation between compilation-time and runtime. > - Enables new use cases: embedded systems, WASM targets, mobile SDKs, > long-lived CLI daemons. You would still be dependent upon the PHP runtime environment. Much like the C# CLR. There is nothing stopping someone from working on OPcache to its natural conclusion and getting the machine code out of it, into a file that can run directly. However, you’re still going to want to run your old code, which most likely calls "exec" somewhere (to compile a twig template), or uses autoloading shenanigans to mock out code, or DI systems that generate new code on demand when you make changes. > > ===== Compatibility Note ===== > This proposal is entirely opt-in and defines a **strict static subset of > PHP**. Dynamic runtime via Zend VM and JIT continues to be supported and > unchanged. This is an addition, not a replacement. > > ===== Request for Feedback ===== > I’d appreciate feedback from internals and community members on: > > - Whether such a compiler pipeline is desirable and feasible. > - Acceptability of the required language subset restrictions. > - Pathways to prototype this outside core, e.g., via PHP extensions or > userland tooling. You may be interested in kphp, which compiles a subset of PHP to machine code. It is still actively developed and maintained. It is a pretty interesting project and has stood the test of time. > > ===== Note ===== > I would like to clarify that I am currently not in a position to implement > this proposal independently, as it would involve deep modifications to the > PHP runtime, compiler pipeline design, or extension interfaces. > > This RFC is submitted with the intention of initiating structured discussion > and community exploration around this long-term direction. I am willing to > contribute research, coordination, and specification work if there is > interest from core contributors. > > I greatly appreciate any feedback, suggestions, or interest in collaborating > on prototyping or feasibility assessment. > > Sincerely, > [wheakerd] — Rob
