Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83509
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
Date: Sun, 22 Feb 2015 18:48:59 -0500
Message-ID: <CAAyV7nGS6TE+JKV8u_P7HXfPi4yYGVh1s_XzSyE+Kbkhv06F-A@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: [PHP-DEV] Coercive Scalar Type Hints RFC
From: ircmaxell@gmail.com (Anthony Ferrara)

Adding in a thread that was started in private, but absolutely is
worth sharing with the group:


---------- Forwarded message ----------
From: Etienne Kneuss <colder@php.net>
Date: Sun, Feb 22, 2015 at 8:42 AM
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
To: Zeev Suraski <zeev@zend.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, Dmitry Stogov <dmitry@zend.com>




On Sun Feb 22 2015 at 14:23:58 Zeev Suraski <zeev@zend.com> wrote:
>
> > There have been several attempts:
> > for JS: http://users-cs.au.dk/simonhj/tajs2009.pdf
> > or similar techniques applied to PHP, quite outdated though:
> > https://github.com/colder/phantm
>
> Looks like WebKit's type inference is doing some pretty good job at
> analyzing code, although I'm not sure how much of it is static vs. dynamic.
> My guess is that a lot of it is static:
> twitter.com/kangax/status/558974257724940288


My guess would be that it's almost entirely dynamic, or probabilistic
(e.g. this nice recent work done at ETH: http://www.jsnice.org/).

I think you underestimate the difficulty of statically recovering
precise types from no-annotations without runtime witnesses ;) You
don't want webkit anlysing the JS for 10 minutes until it renders the
page. It is much more profitable to JIT these.

>
>
>
> > You are right that the lack of static information about types is (one of
> > the) a main issue. Recovering the types has typically a huge performance
> > cost, or is unreliable
>
> We're not really talking about performance issue here, as static analysis is
> a separate activity that is unrelated to runtime performance.


What I meant was: it is a performance issue for the static analyzer,
not PHP itself.

>
>
> > But seriously, time is getting wasted on this argument; it's actually a
> > no-brainer: more static information helps tools that rely on static
> > information. Yes. Absolutely. 100%.
>
> There's still disagreement between us on whether the different behavior of
> Strict STH constitutes additional static information or not, as it doesn't
> give you any extra information on the value being fed to the function, and
> it doesn't give you any extra information on what the function will receive.
> It only gives you information about how the function would behave if it gets
> a wrongly-typed value.



1) for forward analyses (which are the most common for these
applications): it gives you precious information from the beginning of
the function and forward. You can consider it similarly to a cast: You
don't necessarily know what the value coming in is, but you know which
type you are having from that point forward.

2) backward analyses could piggy-back the type constraints from the
functions (strict or no strict) and check that they are met when
constructing the value fed to the function.

Having worked several years on static analysis tools for languages
such as PHP, I can guarantee you that this information would help a
lot. However, the other dynamic feature of PHP would still make
analyses slow/unreliable/imprecise. Let's not imagine that this is the
only thing missing for PHP to be static-analysis-wonderland, far from
it.

>
> But my the bottom line is exactly the bottom line you ended with, and what I
> answered you on-list - how much weight should Static Analysis improvements
> have on our decision to introduce new language features?  My answer is not
> that much, if they have downsides.  Static Analyzers should be designed for
> languages and not vice versa.


I fully agree in general that the flow should be this way. But it
remains a bonus if a certain feature, as a plus, would help external
tools. I believe it is worth mentionning..

>
> Thanks,
>
> Zeev