# [RFC] [Vote] Keywords as identifiers - Thread: https://externals.io/message/69732 - Original archive: https://news-web.php.net/php.internals/69732 - Started by Bob Weinand on 2013-10-21T14:32:05+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #69732 — Bob Weinand — 2013-10-21T14:32:05+00:00 URL: https://externals.io/message/69732#69732 Hi, I have started the vote for extended keyword support RFC: https://wiki.php.net/rfc/keywords_as_identifiers Deadline is Monday, next week (28.10.2013) Bob Weinand --- ## #69745 — Derick Rethans — 2013-10-22T09:11:47+00:00 URL: https://externals.io/message/69732#69745 · In reply to: #69732 > I have started the vote for extended keyword support RFC: > > https://wiki.php.net/rfc/keywords_as_identifiers Just to explain why I voted "no". I think the idea is good, but what I see from the patch is that it adds a *lot* of hand written state machines which are going to be a pain to maintain. I do not think this extra maintenance is worth the features - we've done pretty well without it. cheers, Derick --- ## #69747 — Pierre Joye — 2013-10-22T09:30:09+00:00 URL: https://externals.io/message/69732#69747 · In reply to: #69745 > > > > […] > > Just to explain why I voted "no". I think the idea is good, but what I > see from the patch is that it adds a *lot* of hand written state > machines which are going to be a pain to maintain. I do not think this > extra maintenance is worth the features - we've done pretty well without > it. I did not vote yet, however I agree with Derick. A cleaner solution would be better. We have lived with this restriction for some time already and we may as well delay this RFC until we have a viable technical solution. If anyone feels motivated enough to implement the parser/lexer using other tools :) -- Pierre @pierrejoye | http://www.libgd.org --- ## #69748 — Bob Weinand — 2013-10-22T09:52:45+00:00 URL: https://externals.io/message/69732#69748 · In reply to: #69747 Am 22.10.2013 um 11:30 schrieb Pierre Joye : > > > […] > > I did not vote yet, however I agree with Derick. A cleaner solution > would be better. We have lived with this restriction for some time > already and we may as well delay this RFC until we have a viable > technical solution. If anyone feels motivated enough to implement the > parser/lexer using other tools :) > > > -- > Pierre > > @pierrejoye | http://www.libgd.org Thank you for the feedback, I actually don't think that it would be hard to maintain as it still is only a limited set of keywords where extra conditions are necessary. You rarely should have to change the implementation. If anyone has an idea how I could just write in the parser: "T_STRING or (alphabetic keyword with lowest precedence)" then that'd be very welcome, but I didn't actually find a solution for that without a lot of reduce/reduce conflicts. See also that initial implementation which just involved parser, but had more limited keyword support: https://github.com/bwoebi/php-src/commit/18c78af2d9ff27cf2df3ad0e63f5c4cce11a5db3 Bob Weinand --- ## #69749 — Sebastian Bergmann — 2013-10-22T09:53:04+00:00 URL: https://externals.io/message/69732#69749 · In reply to: #69747 > I did not vote yet, however I agree with Derick. A cleaner solution > would be better. We have lived with this restriction for some time > already and we may as well delay this RFC until we have a viable > technical solution. If anyone feels motivated enough to implement the > parser/lexer using other tools :) The implementation has to be clean and the experience to users has to be consistent. Last time I looked at the RFC the implementation only allowed some keywords to be used in some contexts where keywords could not be used previously. Not allowing all keywords in all contexts only leads to confusion. --- ## #69753 — Bob Weinand — 2013-10-22T10:08:42+00:00 URL: https://externals.io/message/69732#69753 · In reply to: #69749 Am 22.10.2013 um 11:53 schrieb Sebastian Bergmann : > > > […] > > The implementation has to be clean and the experience to users has > to be consistent. Last time I looked at the RFC the implementation > only allowed some keywords to be used in some contexts where keywords > could not be used previously. Not allowing all keywords in all contexts > only leads to confusion. I had announced previously on the list and it's noted in the RFC too, that these inconsistencies had been removed. That's actually not the problem; Pierre and Derick are talking about the implementation in C. Bob Weinand --- ## #69754 — Sebastian Bergmann — 2013-10-22T10:10:51+00:00 URL: https://externals.io/message/69732#69754 · In reply to: #69753 > I had announced previously on the list and it's noted in the RFC too, that > these inconsistencies had been removed. Okay, thanks for the information. > That's actually not the problem; Pierre and Derick are talking about the > implementation in C. I understood the point Pierre and Derick raised. --- ## #69755 — Etienne Kneuss — 2013-10-22T10:25:19+00:00 URL: https://externals.io/message/69732#69755 · In reply to: #69754 Hi, IMHO lifting this "keyword <> identifiers" restriction is a good idea. I'm not sure that it is worth replacing our current keywords though. However, I think it is a very good solution for future language constructs that want to keep BC. So we should at least keep it in mind in case it is rejected. Best, --- ## #69757 — Zeev Suraski — 2013-10-22T10:54:08+00:00 URL: https://externals.io/message/69732#69757 · In reply to: #69745 > -----Original Message----- > From: Derick Rethans [mailto:derick@php.net] > Sent: Tuesday, October 22, 2013 12:12 PM > To: Bob Weinand > Cc: Developers Mailing List PHP > Subject: Re: [PHP-DEV] [RFC] [Vote] Keywords as identifiers > > > > > […] > > Just to explain why I voted "no". I think the idea is good, but what I see from > the patch is that it adds a *lot* of hand written state machines which are > going to be a pain to maintain. I do not think this extra maintenance is worth > the features - we've done pretty well without it. Thumbs up for the idea as well, but I don't think we can live with the implementation. BTW, that's a bit of a grey area but I think that even if an idea is accepted, if there's no reasonably clean implementation available for it, I don't think it can go in. Zeev --- ## #69758 — Bob Weinand — 2013-10-22T11:01:21+00:00 URL: https://externals.io/message/69732#69758 · In reply to: #69757 Am 22.10.2013 um 12:54 schrieb "Zeev Suraski" : > > […] > see from > > […] > are > > […] > worth > > […] > > Thumbs up for the idea as well, but I don't think we can live with the > implementation. BTW, that's a bit of a grey area but I think that even if > an idea is accepted, if there's no reasonably clean implementation > available for it, I don't think it can go in. > > Zeev As said, if anyone has a good idea how to improve the implementation, I'd be happy to implement it. (I really can't imagine a better way...) Bob Weinand (Btw. Is my implementation so bad? I think it looks far worse than it is in reality...) --- ## #69764 — Derick Rethans — 2013-10-22T12:28:02+00:00 URL: https://externals.io/message/69732#69764 · In reply to: #69758 > Am 22.10.2013 um 12:54 schrieb "Zeev Suraski" : > > > […] > > As said, if anyone has a good idea how to improve the implementation, > I'd be happy to implement it. That's not an excuse for adding code that people disagree with. > Btw. Is my implementation so bad? I think it looks far worse than it > is in reality...) You add 350 lines of almost-hand-crafted parsing to the lexer, which I consider "modereately bad". My point is that I don't think it's worth this extra complication for a "not really important" feature. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine --- ## #69765 — Bob Weinand — 2013-10-22T12:55:32+00:00 URL: https://externals.io/message/69732#69765 · In reply to: #69764 Am 22.10.2013 um 14:28 schrieb Derick Rethans : > > > […] > > That's not an excuse for adding code that people disagree with. I agree, but if people disagree, then I'd like to hear which code they'd prefer. > > […] > > You add 350 lines of almost-hand-crafted parsing to the lexer, which I > consider "modereately bad". My point is that I don't think it's worth > this extra complication for a "not really important" feature. About 150 lines parsing, the other are macros and other logic. Actually syntax is mostly: if (buf_one_token == T_TOKEN && LEX_IS_CUR_ALPH_TOKEN()) { LEX_CONVERT_CUR_STRING(); } That's not much more complicated than just writing something like: T_TOKEN ALPH_TOKEN { LEX_CONVERT_CUR_STRING(); } in a bison/yacc parser. ___ Also, it is not a really complication; it's just a transparent additional step you usually don't have to modify and could even remove without loosing any features except the keyword support. Bob Weinand --- ## #69781 — Stas Malyshev — 2013-10-22T20:35:11+00:00 URL: https://externals.io/message/69732#69781 · In reply to: #69745 Hi! > Just to explain why I voted "no". I think the idea is good, but what I > see from the patch is that it adds a *lot* of hand written state > machines which are going to be a pain to maintain. I do not think this > extra maintenance is worth the features - we've done pretty well without > it. Exactly the same here. I love the idea, but looking at the code I realize even with my experience about what's going on in the engine I have hard time understanding what's going on there, and we're not talking about some obscure nook of the engine - parser is right in the middle of everything. So I personally adding so much complexity is not worth the cost. If we can find a solution to do the same (or roughly the same, sacrificing some less important features) without adding so much complexity it'd be much better I think. Maybe if you made a good narrative explanation what's going on in that code and it turned out it's not as bad as it looks and we just didn't realize it, it would be more acceptable. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #69782 — Zeev Suraski — 2013-10-22T20:40:21+00:00 URL: https://externals.io/message/69732#69782 · In reply to: #69758 > > […] > > As said, if anyone has a good idea how to improve the implementation, I'd > be happy to implement it. > > (I really can't imagine a better way...) I think the point that Derick is trying to make, and that I agree with - is that if there's no better way to implement it we shouldn't be implementing it at all. In other words, coming up with a clean implementation is a requirement before we can go ahead and introduce this feature into the language. I did not mean to imply you did a poor job implementing it, I don't presently have an idea of how to make it better. Zeev --- ## #69787 — Clint Priest — 2013-10-23T00:19:58+00:00 URL: https://externals.io/message/69732#69787 · In reply to: #69781 I just wanted to +1 for the idea but agree with Stas, Derrick and Zeev on the implementation, a simpler way needs to be found to solve the problem. > Hi! > > > […] > Exactly the same here. I love the idea, but looking at the code I > realize even with my experience about what's going on in the engine I > have hard time understanding what's going on there, and we're not > talking about some obscure nook of the engine - parser is right in the > middle of everything. So I personally adding so much complexity is not > worth the cost. If we can find a solution to do the same (or roughly the > same, sacrificing some less important features) without adding so much > complexity it'd be much better I think. > Maybe if you made a good narrative explanation what's going on in that > code and it turned out it's not as bad as it looks and we just didn't > realize it, it would be more acceptable. --- ## #69797 — guilhermeblanco@gmail.com — 2013-10-23T04:38:45+00:00 URL: https://externals.io/message/69732#69797 · In reply to: #69787 +1 on idea -1 on implementation > I just wanted to +1 for the idea but agree with Stas, Derrick and Zeev on > the implementation, a simpler way needs to be found to solve the problem. > > > > > > […] > > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- ## #69842 — Julien Pauli — 2013-10-24T13:37:10+00:00 URL: https://externals.io/message/69732#69842 · In reply to: #69782 > > […] > I'd > > […] > > I think the point that Derick is trying to make, and that I agree with - > is that if there's no better way to implement it we shouldn't be > implementing it at all. In other words, coming up with a clean > implementation is a requirement before we can go ahead and introduce this > feature into the language. I did not mean to imply you did a poor job > implementing it, I don't presently have an idea of how to make it better. > I'm all +1 with that. Don't forget that we have been leaving with those reserved keyword for ~15y now, and just right. I don't think we should hurry on such a feature adding so much complicated stuff, especially to the lexer. Julien.Pauli --- ## #69845 — Kevin Ingwersen — 2013-10-24T14:35:23+00:00 URL: https://externals.io/message/69732#69845 · In reply to: #69842 Hello there! I just recently joined the mailing list - what is this vote about? Kind regards, Kevin Ingwersen Am 24.10.2013 um 15:37 schrieb Julien Pauli : > > > > […] > > I'm all +1 with that. > > Don't forget that we have been leaving with those reserved keyword for ~15y > now, and just right. > I don't think we should hurry on such a feature adding so much complicated > stuff, especially to the lexer. > > Julien.Pauli