Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127670
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 16 Jun 2025 15:05:30 +0800
Message-ID: <CAFJdCSsHhY6nAvjhCcohZxDtiQS=8B0=1RYH-ZyK+nW8xX6CrQ@mail.gmail.com>
Subject: [PHP-DEV] [RFC] RFC Discussion - CLI-Only Development Mode and AOT Compilation Architecture
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000025e51d0637ab0677"
From: wheakerd@gmail.com (wheakerd)

--00000000000025e51d0637ab0677
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=99s traditional interpreter-b=
ased
design, I believe it opens up valuable opportunities to modernize PHP's
runtime and improve performance, portability, and long-term maintainability=
.

=3D=3D=3D=3D=3D Current Development Landscape =3D=3D=3D=3D=3D
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.

=3D=3D=3D=3D=3D Motivation =3D=3D=3D=3D=3D
PHP=E2=80=99s traditional runtime model (FPM or mod_php) is optimized for
short-lived, script-based execution. However, this limits PHP=E2=80=99s pot=
ential
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.

=3D=3D=3D=3D=3D Proposal =3D=3D=3D=3D=3D
### 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=3D1)`, 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.

=3D=3D=3D=3D=3D Expected Benefits =3D=3D=3D=3D=3D
- Native, standalone executables=E2=80=94no 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.

=3D=3D=3D=3D=3D Compatibility Note =3D=3D=3D=3D=3D
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.

=3D=3D=3D=3D=3D Request for Feedback =3D=3D=3D=3D=3D
I=E2=80=99d 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.

=3D=3D=3D=3D=3D Note =3D=3D=3D=3D=3D
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]

--00000000000025e51d0637ab0677
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Dear PHP Internals,<br><br>I am submittin=
g this proposal for discussion regarding a potential future direction for P=
HP: moving toward a CLI-only development model and introducing an optional =
Ahead-of-Time (AOT) compilation infrastructure.<br><br>While this may not f=
ully align with PHP=E2=80=99s traditional interpreter-based design, I belie=
ve it opens up valuable opportunities to modernize PHP&#39;s runtime and im=
prove performance, portability, and long-term maintainability.<br><br>=3D=
=3D=3D=3D=3D Current Development Landscape =3D=3D=3D=3D=3D<br>Contemporary =
PHP projects are already moving toward architecture patterns that resemble =
compiled systems:<br><br>- Frameworks define service containers, dependency=
 graphs, and code generation layers.<br>- Static analysis tools (Psalm, PHP=
Stan) are integral to modern development.<br>- Code is often bootstrapped t=
hrough CLI pipelines: for build, testing, deployment, and even request simu=
lation (`php artisan`, `bin/console`, etc.).<br>- Composer autoloading, ann=
otation processors, and classmaps are precomputed.<br>- Web servers (e.g., =
Swoole, RoadRunner) are replacing FPM in performance-critical applications,=
 with CLI processes becoming long-lived daemons.<br><br>All of this reflect=
s a growing shift: **PHP is increasingly behaving like a static backend lan=
guage**, except it still runs on a dynamic interpreter.<br><br>This proposa=
l attempts to provide native language support and compiler infrastructure t=
hat aligns with these modern PHP usage patterns.<br><br>=3D=3D=3D=3D=3D Mot=
ivation =3D=3D=3D=3D=3D<br>PHP=E2=80=99s traditional runtime model (FPM or =
mod_php) is optimized for short-lived, script-based execution. However, thi=
s limits PHP=E2=80=99s potential in:<br><br>- Serverless or event-driven en=
vironments (high cold start cost).<br>- Embedded targets and containers wit=
h limited runtime support.<br>- Modular system design where PHP extensions =
must be written in C.<br>- Distributable binaries for CLI tools or desktop-=
style apps.<br><br>PHP developers are often forced to work around these lim=
itations using complex workarounds (e.g., caching containers, annotation sc=
ans, custom autoloaders, preload hacks). AOT compilation and CLI-first desi=
gn can solve these challenges directly, natively.<br><br>=3D=3D=3D=3D=3D Pr=
oposal =3D=3D=3D=3D=3D<br>### 1. Compiler Infrastructure (AOT Mode)<br>A ne=
w compiler pipeline would be introduced:<br><br>- **Frontend**: Parse PHP s=
ource into AST (reusing current infrastructure).<br>- **IR Layer**: Transfo=
rm AST into intermediate representation (IR).<br>- **Backend**: Compile IR =
into native binary via C transpilation or LLVM backend.<br><br>### 2. Requi=
red Language Model Changes<br>To make PHP compilable in AOT mode, certain d=
ynamic features must be restricted or restructured. The following are requi=
red:<br><br>#### a. **Static Code &amp; Configuration**<br>- Dynamic constr=
ucts (e.g., `eval`, dynamic includes/classes/functions) are disallowed.<br>=
- Project must provide static configuration file (`php.compiler.json`) for =
classmap, entrypoint, environment constants, etc.<br>- No runtime-based cod=
e discovery or composition.<br><br>#### b. **Unified Standard Library**<br>=
- Procedural global functions (e.g., `strlen`, `array_merge`) are consolida=
ted into base classes (e.g., `Str::len()`, `Arr::merge()`).<br>- Modules ga=
in clearer boundaries and dependency injection support.<br><br>#### c. **En=
vironment Interfaces**<br>- Superglobals (`$_ENV`, `$_SERVER`, etc.) are ab=
stracted via interfaces or injectable system services.<br><br>#### d. **Typ=
e System Enhancements**<br>- Strong use of `declare(strict_types=3D1)`, int=
erfaces, final classes, and property types.<br>- Optional compilation-time =
type enforcement and inference.<br><br>#### e. **Compiler Extension Hooks**=
<br>- Developers or frameworks can hook into compilation stages (AST transf=
ormation, IR passes) to generate optimized artifacts.<br><br>### 3. CLI-Onl=
y Development Focus<br>- CLI becomes the canonical platform for PHP executi=
on and development.<br>- PHP-FPM and SAPI models remain available for backw=
ard compatibility but are **not required** for future application delivery.=
<br>- Built-in CLI runners or Web adapters (e.g., `php serve`, Swoole adapt=
ers) provide development/testing environments.<br><br>=3D=3D=3D=3D=3D Expec=
ted Benefits =3D=3D=3D=3D=3D<br>- Native, standalone executables=E2=80=94no=
 PHP interpreter dependency.<br>- Fast cold start (useful in serverless and=
 event-driven environments).<br>- PHP extensions can be authored in PHP and=
 compiled, removing the C barrier.<br>- Clean separation between compilatio=
n-time and runtime.<br>- Enables new use cases: embedded systems, WASM targ=
ets, mobile SDKs, long-lived CLI daemons.<br><br>=3D=3D=3D=3D=3D Compatibil=
ity Note =3D=3D=3D=3D=3D<br>This proposal is entirely opt-in and defines a =
**strict static subset of PHP**. Dynamic runtime via Zend VM and JIT contin=
ues to be supported and unchanged. This is an addition, not a replacement.<=
br><br>=3D=3D=3D=3D=3D Request for Feedback =3D=3D=3D=3D=3D<br>I=E2=80=99d =
appreciate feedback from internals and community members on:<br><br>- Wheth=
er such a compiler pipeline is desirable and feasible.<br>- Acceptability o=
f the required language subset restrictions.<br>- Pathways to prototype thi=
s outside core, e.g., via PHP extensions or userland tooling.</div><div><br=
></div><div>=3D=3D=3D=3D=3D Note =3D=3D=3D=3D=3D<br>I would like to clarify=
 that I am currently not in a position to implement this proposal independe=
ntly, as it would involve deep modifications to the PHP runtime, compiler p=
ipeline design, or extension interfaces.<br><br>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, coor=
dination, and specification work if there is interest from core contributor=
s.<br><br>I greatly appreciate any feedback, suggestions, or interest in co=
llaborating on prototyping or feasibility assessment.</div><br>Sincerely,=
=C2=A0<br>[wheakerd]
</div>

--00000000000025e51d0637ab0677--