Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83506
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.179 as permitted sender)
References: <2e4694f9805ee81ea0b2c79eab06c2d6@mail.gmail.com> <CAAyV7nExeZ1xouJAsACm9AvAGuQw0e-0FgVdEOAyzsC5OEn5_Q@mail.gmail.com>
In-Reply-To: <CAAyV7nExeZ1xouJAsACm9AvAGuQw0e-0FgVdEOAyzsC5OEn5_Q@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQIDXD7ehmaYKzbAddTs7O1sB4MzmgIw+OLdnIWrpVA=
Date: Mon, 23 Feb 2015 01:25:31 +0200
Message-ID: <83921f861c3378dfc6ea34b6681f2edd@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.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: zeev@zend.com (Zeev Suraski)

Anthony,

I started writing this long response, but instead, I want to localize the
whole discussion to the one true root difference.  Your position on that
difference is the basis for your entire case, and my position on this
argument is the base for my entire case.

There we go:

> And note that this can only work with strict types since you can do the
> necessary type inference and reconstruction (both forward from a function
> call, and backwards before it).

Please do explain how strict type hints help you do inference that you
couldn't do with dynamic type hints.  Ultimately, your whole argument hinges
on that, but you mention it in parentheses almost as an afterthought.
I claim the opposite - you cannot infer ANYTHING from Strict STH that you
cannot infer from Coercive STH.  Consequently, everything you've shown, down
to the C-optimized version of strict_foo() can be implemented in the exact
same way for very_lax_foo().  Being able to optimize away the value
containers is not unique to languages with strict type hints.  It's done in
JavaScript JIT engines, and it was done in our JIT POC.

> With lax (weak, coercive) types, the ability to do type reconstruction
> drops
> significantly. Because you can no longer do any backwards inference from
> other function calls. Which means you can't prove if a type is stable in
> most
> cases (won't change). Therefore, you'll always have to allocate a ZVAL,
> and
> then the optimizations I showed above would stop working.

Again, using the scientific method I'm familiar with, that would be a
theory, and it would require proof.  So far I haven't seen any proof, and I
believe I pretty much proved the opposite with my example.

Zeev