Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83306 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11856 invoked from network); 20 Feb 2015 14:55:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Feb 2015 14:55:06 -0000 Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.215.50 mail-la0-f50.google.com Received: from [209.85.215.50] ([209.85.215.50:34954] helo=mail-la0-f50.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 27/F8-54878-7CA47E45 for ; Fri, 20 Feb 2015 09:55:05 -0500 Received: by labgm9 with SMTP id gm9so6658981lab.2 for ; Fri, 20 Feb 2015 06:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NNKAzrnOH5Qt8Jp1aoiYwmUvop5TQqvtr/72GDAsVJk=; b=zel1/LNWtiY3xctiKbELKcduxeWWsLeYcuj1j5yJLru8TFSN32Si6zwzttlF91TPdC dYOZU/OqUiHnxJQLZKJktwR4rkI383qOhtc3L8Qgqu2iNJW7Y1hG04NcrYyCfBvfxQvt iz+5bG6lkmbRl0rZFt47vEIhWDwGT0+urlSKgpDdCF6HTJb85WRfuJDwskAQVZ70tO3L yk4/clGYG5KK9FKQlmMQsPW+XQRCARQU0krmZvVK0vIeOOiTQXkGI5CRHZEMJF/fFWt8 C0gSpLCtUJCbFk/ukm+qCsD+LOo8Lae4esOoGS1bP8Vu1LTAxNsfdWamJaIzWJejBmgu cDow== MIME-Version: 1.0 X-Received: by 10.112.170.72 with SMTP id ak8mr8407113lbc.95.1424444101056; Fri, 20 Feb 2015 06:55:01 -0800 (PST) Received: by 10.25.43.9 with HTTP; Fri, 20 Feb 2015 06:55:00 -0800 (PST) In-Reply-To: References: <011801d04a07$83ab1c00$8b015400$@php.net> <016f01d04a3a$e9183220$bb489660$@php.net> <022801d04ab1$4a0c47d0$de24d770$@php.net> <1913e09d7f52541901d8574d2080a63f@mail.gmail.com> <7a5d96b34b98ec1f3ee17be7fa6a1e81@mail.gmail.com> <2CBDEB67-3DE3-437D-9AF3-0E6A92027244@zend.com> <4cc0c81c7199a452534bb8edcdb19914@mail.gmail.com> <54E589F6.9030002@garfieldtech.com> <54E66569.8000709@garfieldtech.com> Date: Fri, 20 Feb 2015 09:55:00 -0500 Message-ID: To: Dmitry Stogov Cc: Pierre Joye , Larry Garfield , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] Reviving scalar type hints From: ircmaxell@gmail.com (Anthony Ferrara) Dmitry On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov wrote: > > > On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye wrote: >> >> hi Dmitry, >> >> On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov wrote: >> > On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara >> > wrote: >> > >> >> Larry, >> >> >> >> > Anthony, can you expand here at all about the practical benefits of >> >> > strong-typing for variable passing for the compiler? That seems to >> >> > be >> >> the >> >> > main point of contention: Whether or not there are real, practical >> >> benefits >> >> > to be had in the compiler of knowing that a call will be in "strict >> >> mode". >> >> > (If there are, then the split-mode makes sense If there are not, >> >> > then >> >> > there's little benefit to it.) >> >> >> >> For the normal compiler & engine there will be no benefit for the >> >> foreseeable future. >> >> >> >> For a tracing JIT compiler, there will be no advantage. >> >> >> >> For a local JIT compiler, there can be some optimizations around >> >> reduced conversion logic generated (and hence potentially better cache >> >> efficiency, etc). A guard would still be generated, but that's a >> >> single branch rather than the full cast logic. This would likely be a >> >> small gain (likely less than 1%, possibly significantly less). >> >> >> >> For a AOT compiler (optimizing compiler), more optimizations and >> >> therefore gains can be had. The big difference here is that type >> >> assertions can be done at compile time. >> > >> > >> > AOT compiler that know type of passed argument and expected parameter >> > type, >> > may eliminate guard check independently on hint semantic (strong or >> > week). >> > If you don't know first or second you'll have to generate guard code >> > anyway >> > independently from hint semantic (strong or week). Is this wrong? >> > >> > We may introduce strong type hints because of your mistake. >> >> >> May, could, would, all that are totally irrelevant to the debate about >> type hinting. The speed benefit is not significant. > > > What is significant? Miracle ability of static analyzes for AOT? Please, can we discuss something without snark? And can we get past AOT? It's distracting. I only mentioned it here because I was specifically asked about it. It's not in my RFC. So please, let's get past it. >> I think we can agree on that, and we did as far as I can tell :) > > > I didn't agree with you. > Probably, I told that performance impact of run-time switch of type hinting > semantic is slightly negative and it would be great to fix it if possible. Everyone is saying this shouldn't be voted on based on performance. You, me, Pierre, everyone. Additionally, the negative impact could be solved by introducing a new opcode for scalar checks, pushing any performance difference to compile time. But I'd like to see some measurments of the performance difference prior to going down that road. In short, the negative performance difference is either going to be negligible (won't appear on a benchmark) or can more than likely be made negligible without a terrible amount of work. >> >> > >> >> However, I think making this decision based on performance is the >> >> incorrect way of doing it. For the Zend engine, there will be no >> >> discernible difference between the proposals. It's a red herring. The >> >> difference I would focus on is the ability to statically analyze the >> >> code (with the benefits that comes with). >> >> >> > >> > Completely agree, changing language for compiler is not fair. >> > It's clear that statically typed languages are more suitable but we >> > won't >> > make PHP statically typed. >> > Also, modern JS engines showed - what they may do without typing. >> >> Let put things correctly please: >> >> > In my opinion strict type hints may be useful for program verification, >> > but >> > again, I wouldn't like to change the whole language semantic >> >> >> >> We are talking about arguments handling here. Not the whole language >> semantic. The way the language works will stay the same. I am not >> writing that for you but for all other who may be misinterpret your >> reply. >> >> > just to get few unit tests out of the box. >> >> Strict types handling for arguments goes way beyond having a few units >> tests. It would very good if one single point of the argumentation is >> used to generalize a cons argument. That makes no sense and it simply >> goes down a way I would really not like to see again. > > > I didn't hear any arguments for strict typing except for program > verification and static analyzes, may be I missed. > Please, tell me few use cases, may be it'll change my mind :) verification and static analysis aren't enough? Seriously, equating static analysis to "a few unit tests" is either un-unnecessarily hyperbolic or a complete misconsurance of the point. "Unit tests" at best tell you that the code behaves as the tests say. Those tests can be bogus, but the tests still pass. Static analysis on the other hand can tell you if the code is semantically correct or not (whether or not errors can/will be thrown). The type system provides a lower bound on correctness. The "unit tests" at best establish an upper bound. For a 1,000 line-of-code application written by a single developer, the difference is trivial. For a 10,000 line-of-code application written by 2 developers, it's likely not going to make a massive difference. But for a 100,000 line-of-code or 1,000,000 line-of-code or 10,000,000 line-of-code application written and maintained by dozens of developers, it becomes massively important. There's a reason large companies are investing massive amounts of money into statically typed languages (Hack, Go, Rust, etc). For a sense of scale, Symfony 2 framework in PHP is 129838 non-comment lines of code. With over 1000 contributors. That's not saying you should want to use statically typed for everything. And nor would I support PHP moving to pure statically typed (which is why the proposal I'm backing doesn't). Instead, what I'm suggesting is to keep with the philosophy of PHP 5's object system. Strongly typed when user choose, but it's optional. That way the user is empowered to make the decisions best for them. Anthony On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov wrote: > > > On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye wrote: >> >> hi Dmitry, >> >> On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov wrote: >> > On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara >> > wrote: >> > >> >> Larry, >> >> >> >> > Anthony, can you expand here at all about the practical benefits of >> >> > strong-typing for variable passing for the compiler? That seems to >> >> > be >> >> the >> >> > main point of contention: Whether or not there are real, practical >> >> benefits >> >> > to be had in the compiler of knowing that a call will be in "strict >> >> mode". >> >> > (If there are, then the split-mode makes sense If there are not, >> >> > then >> >> > there's little benefit to it.) >> >> >> >> For the normal compiler & engine there will be no benefit for the >> >> foreseeable future. >> >> >> >> For a tracing JIT compiler, there will be no advantage. >> >> >> >> For a local JIT compiler, there can be some optimizations around >> >> reduced conversion logic generated (and hence potentially better cache >> >> efficiency, etc). A guard would still be generated, but that's a >> >> single branch rather than the full cast logic. This would likely be a >> >> small gain (likely less than 1%, possibly significantly less). >> >> >> >> For a AOT compiler (optimizing compiler), more optimizations and >> >> therefore gains can be had. The big difference here is that type >> >> assertions can be done at compile time. >> > >> > >> > AOT compiler that know type of passed argument and expected parameter >> > type, >> > may eliminate guard check independently on hint semantic (strong or >> > week). >> > If you don't know first or second you'll have to generate guard code >> > anyway >> > independently from hint semantic (strong or week). Is this wrong? >> > >> > We may introduce strong type hints because of your mistake. >> >> >> May, could, would, all that are totally irrelevant to the debate about >> type hinting. The speed benefit is not significant. > > > What is significant? Miracle ability of static analyzes for AOT? > >> I think we can agree on that, and we did as far as I can tell :) > > > I didn't agree with you. > Probably, I told that performance impact of run-time switch of type hinting > semantic is slightly negative and it would be great to fix it if possible. > >> >> > >> >> However, I think making this decision based on performance is the >> >> incorrect way of doing it. For the Zend engine, there will be no >> >> discernible difference between the proposals. It's a red herring. The >> >> difference I would focus on is the ability to statically analyze the >> >> code (with the benefits that comes with). >> >> >> > >> > Completely agree, changing language for compiler is not fair. >> > It's clear that statically typed languages are more suitable but we >> > won't >> > make PHP statically typed. >> > Also, modern JS engines showed - what they may do without typing. >> >> Let put things correctly please: >> >> > In my opinion strict type hints may be useful for program verification, >> > but >> > again, I wouldn't like to change the whole language semantic >> >> >> >> We are talking about arguments handling here. Not the whole language >> semantic. The way the language works will stay the same. I am not >> writing that for you but for all other who may be misinterpret your >> reply. >> >> > just to get few unit tests out of the box. >> >> Strict types handling for arguments goes way beyond having a few units >> tests. It would very good if one single point of the argumentation is >> used to generalize a cons argument. That makes no sense and it simply >> goes down a way I would really not like to see again. > > > I didn't hear any arguments for strict typing except for program > verification and static analyzes, may be I missed. > Please, tell me few use cases, may be it'll change my mind :) > > Thanks. Dmitry. > > >> >> Cheers, >> -- >> Pierre >> >> @pierrejoye | http://www.libgd.org > >