Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83574
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <005801d04f73$2c59a450$850cecf0$@tutteli.ch>
References: <2e4694f9805ee81ea0b2c79eab06c2d6@mail.gmail.com>
	<CAAyV7nExeZ1xouJAsACm9AvAGuQw0e-0FgVdEOAyzsC5OEn5_Q@mail.gmail.com>
	<54EA5EDA.8010605@gmail.com>
	<CAAyV7nFt3KL_uH4HuA5xQ7HY+3_3=fq=pg0_U1aMrdirETC6LQ@mail.gmail.com>
	<54EA6A99.5010609@gmail.com>
	<CAAyV7nE2Cfr0ohpPnXWnf5agmyGfeirNH-3UGyHEhsDaMvmsoQ@mail.gmail.com>
	<54EA7F15.9030606@gmail.com>
	<54EA891B.6030405@gmail.com>
	<09b9ee836c04b1750614a91bd39a5bed@mail.gmail.com>
	<54EA97A2.4010701@gmail.com>
	<CAL=_i_nn_az7gsu2Y7Qhp29cP1gJ96T_0SmG60rhY12qKvr6qA@mail.gmail.com>
	<003901d04f42$8ec315d0$ac494170$@tutteli.ch>
	<CAAyV7nEOT76pAVMO7pBsv7kJwQ+S8+zBrcZJEFrS4fbtw2-W7Q@mail.gmail.com>
	<005801d04f73$2c59a450$850cecf0$@tutteli.ch>
Date: Mon, 23 Feb 2015 09:28:27 -0500
Message-ID: <CAAyV7nH4cfa4Knan0JyN+JgWG46L85xn5BDZq+za4y+=yc5z-g@mail.gmail.com>
To: Robert Stoll <php@tutteli.ch>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
From: ircmaxell@gmail.com (Anthony Ferrara)

Robert,

> [Robert Stoll]
> Sure, "a" was just an example to illustrate the problem. I figured it wou=
ld not be necessary to say that the value of $b can be completely unknown b=
y the static analyser -> could come from user input, from a database, from =
unserialising code etc. (but probably that is what you meant with "this isn=
't the general case" below).
>
> Assuming statically that $a is int or $b is string is erroneous in this c=
ontext.
>
> Another problem to illustrate that a top type or at least some form of un=
ion type is required:
>
> function foo($x, $y, $z){
>   $a =3D 1;
>   if($x){
>     $a =3D "1";
>   }
>   If($y > 10){
>     $a =3D [];
>   }
>   If($z->foo() < 100){
>     $a =3D new Exception();
>   }
>   echo $a;
>   return $a;
> }
>
> How do you want to type $a without using a union type?

Actually, this case is reasonably easy to handle. There's a
representation called SSA (Static-Single-Assignment) that you move
code to prior to doing type analysis. Basically, at a really high
level, it would rewrite the code to this:

function foo($x, $y, $z){
   $a =3D 1;
   if($x){
      $a1 =3D "1";
   }
   $a2 =3D =CE=A6($a, $a1);
  If($y > 10){
    $a3 =3D [];
  }
  $a4 =3D =CE=A6($a2, $a3);
  If($z->foo() < 100){
    $a5 =3D new Exception();
  }
  $a6 =3D =CE=A6($a4, $a5);
  echo $a6;
  return $a6;
}

Where =CE=A6 is a function that chooses the value based on the branch of
the graph that entered it.

There are a few ways to implement it in practice, one would be to
generate a variant. But another would be to generate different code
paths. Considering that $a5 will be the result if $z->foo() < 1000 no
matter what the prior conditionals are, you could invert the code to
push that check first, making it:

function foo($x, $y, $z) {
    if ($z->foo() < 1000) {
        $a =3D new Exception();
        echo $a;
        return $a;
    }
    if ($y > 10) {
        echo [];
        return [];
    }
    if ($x) {
        echo "1";
        return "1";
    }
    echo 1;
    return 1;
}

That transform can be done by the compiler, and hence never need you
to do anything. We still compiled without variants, and the analysis
job wasn't that difficult.

There will be cases of course where this won't work. And in those
cases we could either not compile, or generate a variant.

However, I would like to point out something. If you added a return
type, and ran that code in strict mode, it would error. A static
analyzer can pick up that error and tell you about it.

So really, we're not talking about valid strict code here (tho the
same problem does exist inside strict bodies, and techniques can be
done here the same.

For more info, check out:
https://github.com/google/recki-ct/blob/master/doc/5_phi_resolving.md

>>
>> And hence know **at compile time** that's an error.
>>
>> This isn't the general case, but we can error in that case (from a stati=
c analysis perspective at least) and say "this code is too
>> dynamic". In strict mode at least.
>
> [Robert Stoll]
> If you go and implement a more conservative type system than the actual d=
ynamic type system of PHP well then... you can do whatever you want of cour=
se.
> But if you do not just want to support just a limited set of PHP then you=
 will need to include dynamic checks in many places. Or do you think that i=
s not true?

I think with strict type declarations, the 'limitations' are far less
than you'd think. Yes, there will be cases (like variable variables,
etc) where valid strict code won't be analyzable. But I haven't seen
var-vars in the wild in a while. So I think my assertion is fair: the
majority of *valid* strict-typed code will be analyzable. Where the
majority of coercive won't be.

Anthony