Hi Anthony, On Fri, Feb 20, 2015 at 5:55 PM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> 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. > 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 <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 > > > > >
