> -----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?
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.
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?
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.
> 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.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
