Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83329 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 65385 invoked from network); 20 Feb 2015 17:26:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Feb 2015 17:26:41 -0000 Authentication-Results: pb1.pair.com header.from=dmitry@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=dmitry@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.181 as permitted sender) X-PHP-List-Original-Sender: dmitry@zend.com X-Host-Fingerprint: 209.85.220.181 mail-vc0-f181.google.com Received: from [209.85.220.181] ([209.85.220.181:42638] helo=mail-vc0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 34/58-14173-05E67E45 for ; Fri, 20 Feb 2015 12:26:40 -0500 Received: by mail-vc0-f181.google.com with SMTP id im6so3428075vcb.12 for ; Fri, 20 Feb 2015 09:26:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ngczk7nBQhgVZ6KnarFoOBRuNPmm8chOA2yfD16xbqM=; b=Xa8s59X776yAdZAOAH5Jh9IyXo46OGjBpS6S/aGugd551cAg6rePzLq1l8F6wB6QOb SzoJ1PALbnrmcnosdwHpy+otkR6V1zTQUo0Ay7TvsVnoHkZ3jsezMrhUjUsTqEOF9Bio h7k/etSqN+tR3lZNJfi7SasJXFZtVR57KAXUMfEvwAhZPWcBisylz+m9m/V3BYjM1Qu1 aNQgkZPjPqdTyN7PX7K3i90UciSq6wYNcJhxjTys8Aoyv8ac1yMh3MA8wm8ucycnnJAA BJC484Mo04eg3IWJgj2eE5qY3tZMJczgtOfy374qqz5iz1umjIP1uTdrDlkJkcjw0eRF TUOw== X-Gm-Message-State: ALoCoQmgViUyOIBF6O/JFlM5JixWD7gc8rVwW2rTysg7V/156dipIRC2I+pXOZo5o/Ohpu+GXPQWwmyrFn3bEdD7zvSegUwLx+/gMeUhLM0IZvEVSM/CiwY/O7XTCjwGSq3i9tAZ9zYpbf8+d111pI0pEyw36yc9ZA== MIME-Version: 1.0 X-Received: by 10.52.99.230 with SMTP id et6mr6820456vdb.65.1424453197545; Fri, 20 Feb 2015 09:26:37 -0800 (PST) Received: by 10.52.74.73 with HTTP; Fri, 20 Feb 2015 09:26:37 -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 21:26:37 +0400 Message-ID: To: Anthony Ferrara Cc: Pierre Joye , Larry Garfield , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=20cf3071c7c0d6de3e050f885a1a Subject: Re: [PHP-DEV] Reviving scalar type hints From: dmitry@zend.com (Dmitry Stogov) --20cf3071c7c0d6de3e050f885a1a Content-Type: text/plain; charset=UTF-8 Hi Anthony, On Fri, Feb 20, 2015 at 5:55 PM, Anthony Ferrara wrote: > 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. > sorry, I shouldn't be too emotional. actually, it's hard to express emotions with may bad English :) I think, you are doing a great job regarding AOT, but I think strict types won't help you a lot. We may discuss it out of the list on next week. > >> 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. > Performance is not a stopper for vote, but it doesn't mean it's not important. > > 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. > Currently type checks are performed in ZEND_RECV opcode, so we can't use a special opcode here. We may try to perform checks in ZEND_SEND_... opcodes. If this would work without performance degradation it's great. But we will have to verify all the possible caller mechanism carefully, e.g. direct calls, indirect through call_user_function(), __call(), __get(), error callbacks, etc. Then we won't need to check types in RECV. If you may try to implement this, it would be great. Thanks. Dmitry. > > >> > >> > > >> >> 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 static analyzes you actually don't need strict types in the language itslef. If static analyzer would find type mismatch (that may work with weak hinting rules), it may report a warning. then users may add explicit type conversion. > 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. > But PHP is dynamically typed language and it shouldn't be turned into static. Think about our users, why do they use PHP? because it's simple to use a scripting language. 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. > Argument type hinting is just a first step to make stronger type system, but strong != static. Thanks. Dmitry. > > > 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 > > > > > --20cf3071c7c0d6de3e050f885a1a--