Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127694
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 16 Jun 2025 22:00:50 +0200
To: internals@lists.php.net
Message-ID: <d92bda63-d6a1-4c1f-be2c-d855f1a4d37c@app.fastmail.com>
In-Reply-To: 
 <CAFJdCSsHhY6nAvjhCcohZxDtiQS=8B0=1RYH-ZyK+nW8xX6CrQ@mail.gmail.com>
References: 
 <CAFJdCSsHhY6nAvjhCcohZxDtiQS=8B0=1RYH-ZyK+nW8xX6CrQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] RFC Discussion - CLI-Only Development Mode and AOT
 Compilation Architecture
Content-Type: multipart/alternative;
 boundary=7daf99f6b4a3469e9221f42ebd021a3e
From: rob@bottled.codes ("Rob Landers")

--7daf99f6b4a3469e9221f42ebd021a3e
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Mon, Jun 16, 2025, at 09:05, wheakerd wrote:
> Dear PHP Internals,
>=20
> I am submitting this proposal for discussion regarding a potential fut=
ure direction for PHP: moving toward a CLI-only development model and in=
troducing an optional Ahead-of-Time (AOT) compilation infrastructure.
>=20
> While this may not fully align with PHP=E2=80=99s traditional interpre=
ter-based design, I believe it opens up valuable opportunities to modern=
ize PHP's runtime and improve performance, portability, and long-term ma=
intainability.

We kinda already have this =E2=80=94 to a degree. You can enable pre-loa=
ding and OPcache. In case you aren=E2=80=99t aware (I wasn=E2=80=99t jus=
t 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 =E2=80=94 assuming I read the extension correctly, an=
d I=E2=80=99m fairly confident in that).

> =3D=3D=3D=3D=3D Current Development Landscape =3D=3D=3D=3D=3D
> Contemporary PHP projects are already moving toward architecture patte=
rns that resemble compiled systems:
>=20
> - Frameworks define service containers, dependency graphs, and code ge=
neration layers.
> - Static analysis tools (Psalm, PHPStan) are integral to modern develo=
pment.
> - 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 preco=
mputed.
> - Web servers (e.g., Swoole, RoadRunner) are replacing FPM in performa=
nce-critical applications, with CLI processes becoming long-lived daemon=
s.
>=20
> All of this reflects a growing shift: **PHP is increasingly behaving l=
ike a static backend language**, except it still runs on a dynamic inter=
preter.
>=20
> This proposal attempts to provide native language support and compiler=
 infrastructure that aligns with these modern PHP usage patterns.

I=E2=80=99m unsure why you=E2=80=99re asserting that compiled systems on=
ly use these architectural patterns? They=E2=80=99re patterns and thus c=
an be used in JavaScript, or even Lisp, if you want to. It doesn=E2=80=99=
t mean the language has to be compiled to generate code (in fact, were i=
t a compiled language, generating code would be nigh impossible during r=
untime).

>=20
> =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=99=
s potential in:
>=20
> - 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.
>=20
> 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 s=
olve these challenges directly, natively.

I=E2=80=99m sorry; you=E2=80=99ve lost me here.=20

How does "short-lived" execution fail in serverless or event-driven envi=
ronments? Isn=E2=80=99t that the entire point? Serverless is basically a=
 reinvention of CGI, which PHP excels at. However, the people who built =
these runtimes didn=E2=80=99t realise what they were reinventing to run =
long-lived applications and didn=E2=80=99t include PHP because "PHP is d=
ying" for the last 20 years. This is a failure of the people who built t=
he runtimes, not PHP=E2=80=99s 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 ther=
e is a lot of PHP talent out there quite used to dealing with "shared no=
thing", "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 tha=
t can bind with C libraries (like Go, Zig, Rust, or even C#).

Also, it is false that you can=E2=80=99t distribute CLI tools written in=
 PHP. There is at least one project that lets you bundle your PHP projec=
t in a statically built, self-extracting executable.

> =3D=3D=3D=3D=3D Proposal =3D=3D=3D=3D=3D
> ### 1. Compiler Infrastructure (AOT Mode)
> A new compiler pipeline would be introduced:
>=20
> - **Frontend**: Parse PHP source into AST (reusing current infrastruct=
ure).
> - **IR Layer**: Transform AST into intermediate representation (IR).
> - **Backend**: Compile IR into native binary via C transpilation or LL=
VM backend.
>=20
> ### 2. Required Language Model Changes
> To make PHP compilable in AOT mode, certain dynamic features must be r=
estricted or restructured. The following are required:
>=20
> #### 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.
>=20
> #### b. **Unified Standard Library**
> - Procedural global functions (e.g., `strlen`, `array_merge`) are cons=
olidated into base classes (e.g., `Str::len()`, `Arr::merge()`).
> - Modules gain clearer boundaries and dependency injection support.
>=20
> #### c. **Environment Interfaces**
> - Superglobals (`$_ENV`, `$_SERVER`, etc.) are abstracted via interfac=
es or injectable system services.
>=20
> #### d. **Type System Enhancements**
> - Strong use of `declare(strict_types=3D1)`, interfaces, final classes=
, and property types.
> - Optional compilation-time type enforcement and inference.
>=20
> #### e. **Compiler Extension Hooks**
> - Developers or frameworks can hook into compilation stages (AST trans=
formation, IR passes) to generate optimized artifacts.
>=20
> ### 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 adap=
ters) provide development/testing environments.
>=20
> =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 b=
arrier.
> - 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 t=
o its natural conclusion and getting the machine code out of it, into a =
file that can run directly. However, you=E2=80=99re still going to want =
to run your old code, which most likely calls "exec" somewhere (to compi=
le a twig template), or uses autoloading shenanigans to mock out code, o=
r DI systems that generate new code on demand when you make changes.

>=20
> =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.
>=20
> =3D=3D=3D=3D=3D Request for Feedback =3D=3D=3D=3D=3D
> I=E2=80=99d appreciate feedback from internals and community members o=
n:
>=20
> - 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 int=
eresting project and has stood the test of time.=20

>=20
> =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 imple=
ment this proposal independently, as it would involve deep modifications=
 to the PHP runtime, compiler pipeline design, or extension interfaces.
>=20
> This RFC is submitted with the intention of initiating structured disc=
ussion and community exploration around this long-term direction. I am w=
illing to contribute research, coordination, and specification work if t=
here is interest from core contributors.
>=20
> I greatly appreciate any feedback, suggestions, or interest in collabo=
rating on prototyping or feasibility assessment.
>=20
> Sincerely,=20
> [wheakerd]

=E2=80=94 Rob
--7daf99f6b4a3469e9221f42ebd021a3e
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Mon, Jun 16, 2025, at 09:05, wheakerd wrote:</div><=
blockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div dir=3D=
"ltr"><div>Dear PHP Internals,</div><div><br></div><div>I am submitting =
this proposal for discussion regarding a potential future direction for =
PHP: moving toward a CLI-only development model and introducing an optio=
nal Ahead-of-Time (AOT) compilation infrastructure.</div><div><br></div>=
<div>While this may not fully align with PHP=E2=80=99s traditional inter=
preter-based design, I believe it opens up valuable opportunities to mod=
ernize PHP's runtime and improve performance, portability, and long-term=
 maintainability.</div></div></div></blockquote><div><br></div><div>We k=
inda already have this =E2=80=94 to a degree. You can enable pre-loading=
 and OPcache. In case you aren=E2=80=99t aware (I wasn=E2=80=99t just a =
year ago!) OPcache is quite advanced and does much of the same stuff a t=
raditional compiler does: (transforms the source into an IR and can even=
 run SSA on it =E2=80=94 assuming I read the extension correctly, and I=E2=
=80=99m fairly confident in that).</div><div><br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div dir=3D"ltr"><div>=3D=3D=
=3D=3D=3D Current Development Landscape =3D=3D=3D=3D=3D</div><div>Contem=
porary PHP projects are already moving toward architecture patterns that=
 resemble compiled systems:</div><div><br></div><div>- Frameworks define=
 service containers, dependency graphs, and code generation layers.</div=
><div>- Static analysis tools (Psalm, PHPStan) are integral to modern de=
velopment.</div><div>- Code is often bootstrapped through CLI pipelines:=
 for build, testing, deployment, and even request simulation (`php artis=
an`, `bin/console`, etc.).</div><div>- Composer autoloading, annotation =
processors, and classmaps are precomputed.</div><div>- Web servers (e.g.=
, Swoole, RoadRunner) are replacing FPM in performance-critical applicat=
ions, with CLI processes becoming long-lived daemons.</div><div><br></di=
v><div>All of this reflects a growing shift: **PHP is increasingly behav=
ing like a static backend language**, except it still runs on a dynamic =
interpreter.</div><div><br></div><div>This proposal attempts to provide =
native language support and compiler infrastructure that aligns with the=
se modern PHP usage patterns.</div></div></div></blockquote><div><br></d=
iv><div>I=E2=80=99m unsure why you=E2=80=99re asserting that compiled sy=
stems only use these architectural patterns? They=E2=80=99re patterns an=
d thus can be used in JavaScript, or even Lisp, if you want to. It doesn=
=E2=80=99t mean the language has to be compiled to generate code (in fac=
t, were it a compiled language, generating code would be nigh impossible=
 during runtime).</div><div><br></div><blockquote type=3D"cite" id=3D"qt=
" style=3D""><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><div>=3D=3D=
=3D=3D=3D Motivation =3D=3D=3D=3D=3D</div><div>PHP=E2=80=99s traditional=
 runtime model (FPM or mod_php) is optimized for short-lived, script-bas=
ed execution. However, this limits PHP=E2=80=99s potential in:</div><div=
><br></div><div>- Serverless or event-driven environments (high cold sta=
rt cost).</div><div>- Embedded targets and containers with limited runti=
me support.</div><div>- Modular system design where PHP extensions must =
be written in C.</div><div>- Distributable binaries for CLI tools or des=
ktop-style apps.</div><div><br></div><div>PHP developers are often force=
d to work around these limitations using complex workarounds (e.g., cach=
ing containers, annotation scans, custom autoloaders, preload hacks). AO=
T compilation and CLI-first design can solve these challenges directly, =
natively.</div></div></div></blockquote><div><br></div><div>I=E2=80=99m =
sorry; you=E2=80=99ve lost me here. </div><div><br></div><div>How does "=
short-lived" execution fail in serverless or event-driven environments? =
Isn=E2=80=99t that the entire point? Serverless is basically a reinventi=
on of CGI, which PHP excels at. However, the people who built these runt=
imes didn=E2=80=99t realise what they were reinventing to run long-lived=
 applications and didn=E2=80=99t include PHP because "PHP is dying" for =
the last 20 years. This is a failure of the people who built the runtime=
s, not PHP=E2=80=99s execution model. It is a political issue, not a tec=
hnical one.</div><div><br></div><div>I primarily work with embedded PHP,=
 there is even an ancient book about it (which is how I first got into p=
hp-src). Embedded PHP is where it is at if you ask me. It is a great lan=
guage for it, especially because there is a lot of PHP talent out there =
quite used to dealing with "shared nothing", "stateless", "event driven"=
 architecture.</div><div><br></div><div>Then there is the fact that PHP =
extensions must be written in C. This is a false assertion. They may als=
o be written in C++, or any language that can bind with C libraries (lik=
e Go, Zig, Rust, or even C#).</div><div><br></div><div>Also, it is false=
 that you can=E2=80=99t 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.</div><div><br></div><blockquote type=
=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div dir=3D"ltr"><div>=3D=
=3D=3D=3D=3D Proposal =3D=3D=3D=3D=3D</div><div>### 1. Compiler Infrastr=
ucture (AOT Mode)</div><div>A new compiler pipeline would be introduced:=
</div><div><br></div><div>- **Frontend**: Parse PHP source into AST (reu=
sing current infrastructure).</div><div>- **IR Layer**: Transform AST in=
to intermediate representation (IR).</div><div>- **Backend**: Compile IR=
 into native binary via C transpilation or LLVM backend.</div><div><br><=
/div><div>### 2. Required Language Model Changes</div><div>To make PHP c=
ompilable in AOT mode, certain dynamic features must be restricted or re=
structured. The following are required:</div><div><br></div><div>#### a.=
 **Static Code &amp; Configuration**</div><div>- Dynamic constructs (e.g=
., `eval`, dynamic includes/classes/functions) are disallowed.</div><div=
>- Project must provide static configuration file (`php.compiler.json`) =
for classmap, entrypoint, environment constants, etc.</div><div>- No run=
time-based code discovery or composition.</div><div><br></div><div>#### =
b. **Unified Standard Library**</div><div>- Procedural global functions =
(e.g., `strlen`, `array_merge`) are consolidated into base classes (e.g.=
, `Str::len()`, `Arr::merge()`).</div><div>- Modules gain clearer bounda=
ries and dependency injection support.</div><div><br></div><div>#### c. =
**Environment Interfaces**</div><div>- Superglobals (`$_ENV`, `$_SERVER`=
, etc.) are abstracted via interfaces or injectable system services.</di=
v><div><br></div><div>#### d. **Type System Enhancements**</div><div>- S=
trong use of `declare(strict_types=3D1)`, interfaces, final classes, and=
 property types.</div><div>- Optional compilation-time type enforcement =
and inference.</div><div><br></div><div>#### e. **Compiler Extension Hoo=
ks**</div><div>- Developers or frameworks can hook into compilation stag=
es (AST transformation, IR passes) to generate optimized artifacts.</div=
><div><br></div><div>### 3. CLI-Only Development Focus</div><div>- CLI b=
ecomes the canonical platform for PHP execution and development.</div><d=
iv>- PHP-FPM and SAPI models remain available for backward compatibility=
 but are **not required** for future application delivery.</div><div>- B=
uilt-in CLI runners or Web adapters (e.g., `php serve`, Swoole adapters)=
 provide development/testing environments.</div><div><br></div><div>=3D=3D=
=3D=3D=3D Expected Benefits =3D=3D=3D=3D=3D</div><div>- Native, standalo=
ne executables=E2=80=94no PHP interpreter dependency.</div><div>- Fast c=
old start (useful in serverless and event-driven environments).</div><di=
v>- PHP extensions can be authored in PHP and compiled, removing the C b=
arrier.</div><div>- Clean separation between compilation-time and runtim=
e.</div><div>- Enables new use cases: embedded systems, WASM targets, mo=
bile SDKs, long-lived CLI daemons.</div></div></div></blockquote><div><b=
r></div><div>You would still be dependent upon the PHP runtime environme=
nt. Much like the C# CLR. There is nothing stopping someone from working=
 on OPcache to its natural conclusion and getting the machine code out o=
f it, into a file that can run directly. However, you=E2=80=99re still g=
oing to want to run your old code, which most likely calls "exec" somewh=
ere (to compile a twig template), or uses autoloading shenanigans to moc=
k out code, or DI systems that generate new code on demand when you make=
 changes.<br></div><div><br></div><blockquote type=3D"cite" id=3D"qt" st=
yle=3D""><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><div>=3D=3D=3D=
=3D=3D Compatibility Note =3D=3D=3D=3D=3D</div><div>This proposal is ent=
irely opt-in and defines a **strict static subset of PHP**. Dynamic runt=
ime via Zend VM and JIT continues to be supported and unchanged. This is=
 an addition, not a replacement.</div><div><br></div><div>=3D=3D=3D=3D=3D=
 Request for Feedback =3D=3D=3D=3D=3D</div><div>I=E2=80=99d appreciate f=
eedback from internals and community members on:</div><div><br></div><di=
v>- Whether such a compiler pipeline is desirable and feasible.</div><di=
v>- Acceptability of the required language subset restrictions.</div><di=
v>- Pathways to prototype this outside core, e.g., via PHP extensions or=
 userland tooling.</div></div></div></blockquote><div><br></div><div>You=
 may be interested in kphp, which compiles a subset of PHP to machine co=
de. It is still actively developed and maintained. It is a pretty intere=
sting project and has stood the test of time.&nbsp;</div><div><br></div>=
<blockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div><br=
></div><div><div>=3D=3D=3D=3D=3D Note =3D=3D=3D=3D=3D</div><div>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 PH=
P runtime, compiler pipeline design, or extension interfaces.</div><div>=
<br></div><div>This RFC is submitted with the intention of initiating st=
ructured discussion and community exploration around this long-term dire=
ction. I am willing to contribute research, coordination, and specificat=
ion work if there is interest from core contributors.</div><div><br></di=
v><div>I greatly appreciate any feedback, suggestions, or interest in co=
llaborating on prototyping or feasibility assessment.</div></div><div><b=
r></div><div>Sincerely,&nbsp;</div><div>[wheakerd]</div></div></blockquo=
te><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></h=
tml>
--7daf99f6b4a3469e9221f42ebd021a3e--