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. ===== 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. ===== 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. ===== 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. ===== 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. ===== 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]
