Dmitry On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov <dmi...@zend.com> wrote: > > > On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye <pierre....@gmail.com> wrote: >> >> hi Dmitry, >> >> On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov <dmi...@zend.com> wrote: >> > On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara <ircmax...@gmail.com> >> > 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 <dmi...@zend.com> wrote: > > > On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye <pierre....@gmail.com> wrote: >> >> hi Dmitry, >> >> On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov <dmi...@zend.com> wrote: >> > On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara <ircmax...@gmail.com> >> > 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 > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
