Stas,
On Thu, Feb 19, 2015 at 9:32 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi!
>
>> So rather than go for the 70-75% consensus that we **know** we have,
>
> How we magically know that? We have the (unfinished) vote, which has a
> tiny bit over 66% for the proposal. Where 75% comes from?
Based on the no reasons that people presented, and some back-of-envelope math.
Basically, it seemed like there were three reasons people voted no:
1. They don't like strict (Zeev, etc)
2. They don't like weak (Sebastian, etc)
3. They don't like declare() + int->float issue (Levi, Daniel, etc)
My view was it seemed to be approximately an even split. So if we
assume that, then 33% of the no-voters (approximately) would vote yes
for 0.5 since declare is fixed.
66% + (34% * 33%) == 77%
I rounded down (saying 70-75). And considering that I've talked to at
least 5 people who've said that they would explicitly change from no
to yes for the proposed v0.5, that would be 71%.
Sure, some people may change yes to no. And people may not vote this
time who voted last time. The only way to know for sure is a vote.
Which is why I'm bringing it to a vote. I wouldn't be doing this if I
didn't think it would pass.
>> Saying a problem doesn't exist doesn't make it go away.
>
> Except if it really doesn't exist, so there's nothing to go away :)
> Saying "static analysis" a hundred times doesn't magically makes it a
> strong argument when nobody showed that it's impossible or even much
> harder without it (many _claimed_ that, but I so far have seen very
> little substantiation for these claims).
As someone who's built a static analyzer for PHP, I can say that it is
much harder without strict typing.
The reason is, with strict typing you only need to deal with 8
possible states for every variable (int, float, bool, resource, array,
object, callable, null and string). And many of those states you can
eliminate based on context (you know an argument passed to an int
declared parameter will always be an int).
Without strict typing, you also need to consider virtual states:
castable object (internally implementing get()), stringable object
(implementing __tostring), numeric string ("123"), kind-of numeric
string ("123 abc"), etc. And many of those states *can't* be
eliminated based on context.
So if a static analysis engine models an application as a graph of
potential state changes, the number of edges goes up exponentially
when you can't eliminate possible variable states. So a lot of work
goes into inferring the possible states involved.
An example is that ($a + $b) we know can never produce a string. We
know it can never produce a bool, resource, array, callable or null.
The only things it can produce is an object, an int or a float. So if
we see expressions of the form `$c = ($a + $b)`, we can immediately
deduce something about $c and therefore reduce the number of possible
states.
With strict typing, if we then pass $c to a function expecting int, we
know that C must be an int. Which means that $a and $b therefore
**must** be castable to an integer (otherwise an error will be thrown
down the road). So we've just reduced $a down to 5 types: int, numeric
string, null, bool and castable object (from at least 12). And $b the
same. So our expression has 10 possible valid (non-error-case)
permutations. Down from the approximately 432 possibilities before
hand (12 for $a, 12 for $b, 3 for $c). And that's with unknown $a and
unknown $b.
The only static analysis engine I've come across that does this for
dynamic types is Klee (LLVM project).
With strictly typed $a and $b, the expression drops to 1 possible
permutation. And you can detect if it's a valid one. And many static
analysis engines do this.
It's not that static analysis is impossible without strict typing.
It's that it gets drastically easier. Both in terms of processing
power, and in terms of edge-cases that you need to support.
Does that substantiate the claim? If not, I'm definitely open to
discussing it further.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
