Ze'ev,
On Sun, Feb 22, 2015 at 6:57 PM, Zeev Suraski <z...@zend.com> wrote:
>> -----Original Message-----
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Monday, February 23, 2015 1:35 AM
>> To: Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
>> RFC)
>>
>> Zeev,
>>
>> >> 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.
>>
>> I do here: http://news.php.net/php.internals/83504
>>
>> I'll re-state the specific part in this mail:
>>
>> <?php declare(strict_types=1);
>> function foo(int $int): int {
>> return $int + 1;
>> }
>>
>> function bar(int $something): int {
>> $x = $something / 2;
>> return foo($x);
>> }
>>
>> ^^ In that case, without strict types, you'd have to generate code for
>> both
>> integer and float paths. With strict types, this code is invalid.
>
> Ok, but how does that support your case? That alludes to the functionality
> difference between strict STH and dynamic STH, and perhaps your Static
> Analysis argument.
>
> How does it help you generate better code code?
Because strict types makes that an error case. So I can then tell the
user to fix it. Once they do (via cast, logic change, etc), I know the
types of every variable the entire way through. So I can generate
native code for both calls without using variants.
> Suggesting that the nature of a type hint can help you determine what's the
> value that's going to be passed to it is akin to saying that the size and
> shape of a door can tell you something about the person or beast that's
> standing on the other side. It just can't.
"It just can't" yet it's done all the time. There is working code in
the wild that does exactly that.
It doesn't tell you what's on the other side (which you seem to be
suggesting), but gives you the possibilities **that won't cause
error**.
So then if you find a possibility from the other direction that isn't
in the set of stable possibilities, you can tell the user (because
that would be a runtime error). The division case in the example shows
that.
> Let me illustrate it in a less colorful way.
>
> Snippet 1:
> ... code that deals with $input ...
> foo($input);
>
> function foo(int $x)
> {
> ...
> }
>
>
> Snippet 2:
> ... code that deals with $input ...
> foo($input);
>
> function foo(float $x)
> {
> ...
> }
>
> Question:
> What can you learn from the signatures of foo() in snippet 1 and 2 about the
> type of $input? Does the fact I changed the function signature from snippet
> 1 to 2 somehow affects the type of $input? In what way?
With strict typing at the foo() call site, it tells you that $input
has to be an int or float (respectively between the snippets).
And as the static analyzer traces back, if it finds possibilities that
don't match (for example, if you assigned it directly from $_POST),
it's able to say that either the original assignment or the function
call is an error.
So yes, it does affect the stable-state types that $input can have.
And if we detect an error, we can tell the dev ahead of time about it.
And hence they can make the appropriate fix.
> If I understood you correctly, you're assuming that $input will too come
> over using a strict type hint, which would tell you that it's an int and
> therefore safe. But a coercive type hint will do the exact same job.
No. I'm assuming that $input came from something that we can infer a
type set from. Which is basically anything in the language.
>> You can tell because you know the function foo expects an integer. So you
>> can infer that $x will have to have the type integer due to the future
>> requirement. Which means the expression "$something / 2" must also be an
>> integer. We know that's not the case, so we can raise an error here.
>
> This is static analysis, not better code generation. And it boils down to a
> functionality difference, not performance difference.
That static analysis enables better code generation. Which is
precisely what I said in an earlier post:
http://news.php.net/php.internals/83501 And I showed an example of the
better code generation.
I hope that makes my point a little clearer,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
