Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83519
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6d317b6cce0cc1aaded1dae11218234d@mail.gmail.com>
References: <2e4694f9805ee81ea0b2c79eab06c2d6@mail.gmail.com>
	<CAAyV7nExeZ1xouJAsACm9AvAGuQw0e-0FgVdEOAyzsC5OEn5_Q@mail.gmail.com>
	<83921f861c3378dfc6ea34b6681f2edd@mail.gmail.com>
	<CAAyV7nEhdeXQbUi9jy10M1NyfaV-w1kF=nWeSW0zd8UQh2_dJQ@mail.gmail.com>
	<26a5bb62bd37a3f610b2a6c10f84d855@mail.gmail.com>
	<CAAyV7nEf_q_NkoQrWN1pa_ot8Ype-SCdvJOdpevUsd4y8Kv6pA@mail.gmail.com>
	<6d317b6cce0cc1aaded1dae11218234d@mail.gmail.com>
Date: Sun, 22 Feb 2015 20:02:10 -0500
Message-ID: <CAAyV7nFcGWJOj-R3ZEn8XkGFqzuw1Ef3tx3Ykm3AXg6KxB+wHg@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
From: ircmaxell@gmail.com (Anthony Ferrara)

Zeev,

> I think we are indeed getting somewhere, I hope.
> If I understand correctly, effectively the flow you're talking about in your
> example is this:
>
> 1. The developers tries to run the program.
> 2. It fails because the static analyzer detects float being fed to an int.
> 3. The user changes the code to convert the input to int.
> 4. You can now optimize the whole flow better, since you know for a fact
> it's an int.
>
> Did I describe that correctly?

Partially.

The static analysis and compilation would be pure AOT. So the errors
would be told to the user when they try to analyze the program, not
run it. Similar to HHVM's hh_client.

However, there could be a "runtime compiler" which compiles in PHP's
compile flow (leveraging opcache, etc). In that case, if the type
assertion isn't stable, the function wouldn't be compiled (the
external analyzer would error, here it just doesn't compile). Then the
code would be run under the Zend engine (and error when called).

>> With strict typing at the foo() call site, it tells you that $input has to
>> be an int
>> or float (respectively between the snippets).
>
> I'm not following.
> Are you saying that because foo() expects an int or float respectively,
> $input has to be int or float?  What if $input is really a string?  Or a
> MySQL connection?

So think of it as a graph. When you start the type analysis, there's
one edge between $input and foo() with type mixed. Looking at foo's
argument, you can say that the type of that graph edge must be int.
Therefore it becomes an int. Then, when you look at $input, you see
that it can be other things, and therefore there are unstable states
which can error at runtime.

> Or are you saying that there was a strict type hint in the function that
> contains the call to foo(), so we know it's an int/float respectively?  If
> so, how would it be any different with a coercive type hint?

Not all data gets into a function from a parameter:

function bar() {
    $x = $_POST['data'];
    foo($x);
}

in that case, we know $x can only be a string or an array (unless we
find where that variable was written to in the program). So we know
for a fact that there's a type error, even though it wasn't a
parameter.

Going deeper, we can look at other cases:

function x() {
    if (time() % 360 > 0) {
        return 123;
    }
}

function bar() {
    $x = x();
    foo($x);
}

In this case, we know that x() has two possible types: int/null. That
doesn't satisfy the valid possibilities for foo (int), hence there's a
possible type error.

The key difference is this: Forward analysis (typing $x by assignment)
can tell you valid modes for your program. Backward analysis
(determining $x's type by its usages) can tell you invalid modes for
your program. Combining them gives you more flexibility in
hard-to-infer/reconstruct situations.

Anthony