Adding in a thread that was started in private, but absolutely is worth sharing with the group:
---------- Forwarded message ---------- From: Etienne Kneuss <col...@php.net> Date: Sun, Feb 22, 2015 at 8:42 AM Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC To: Zeev Suraski <z...@zend.com> Cc: Anthony Ferrara <ircmax...@gmail.com>, Dmitry Stogov <dmi...@zend.com> On Sun Feb 22 2015 at 14:23:58 Zeev Suraski <z...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
