> In PHP, the APIs for accessing the HTTP request data and for setting HTTP response headers and sending data are part of the language; in the untyped lambda calculus, they aren't.
That's just a matter of standard libraries, which can exist in the untyped lambda calculus just as easily as in PHP. These APIs are a convenience, nothing more.
> Of course, you can alter the language specification of the untyped lambda calculus to include side effects by specifying that your program will be passed an HTTP request and its output will be sent to the client. But if you alter the language that way, it's not the untyped lambda calculus any longer.
Neither the PHP language nor the lambda calculus define the semantics of the input and output, which depend on the lower software layers and hardware and are outside the scope of language specifications. Applying an additional semantic layer where none existed before is an extension to the specification, not an alteration to the language. There is no such thing as a meaningful program in either the lambda calculus or more common languages like PHP *without* exactly this sort of semantic extension, which is always defined by the implementation, not the abstract language.
Note that PHP programs can exist which have nothing to do with HTTP; witness the php-cli command-line environment. The HTTP CGI I/O semantics are one way to interact with PHP programs, but not the only way.