Everything

php

[RFC] [Vote] Keywords as identifiers

php.internals

Bob Weinand

12 years ago

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

Derick Rethans

12 years ago

On Mon, 21 Oct 2013, Bob Weinand wrote:

> 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

Pierre Joye

12 years ago

On Tue, Oct 22, 2013 at 11:11 AM, Derick Rethans <derick@php.net> wrote:

> On Mon, 21 Oct 2013, Bob Weinand wrote:
>
>> 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.

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

Bob Weinand

12 years ago

Am 22.10.2013 um 11:30 schrieb Pierre Joye <pierre.php@gmail.com>:

> On Tue, Oct 22, 2013 at 11:11 AM, Derick Rethans <derick@php.net> wrote:
>> On Mon, 21 Oct 2013, Bob Weinand wrote:
>>> 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.
>
> 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

Sebastian Bergmann

12 years ago

On 10/22/2013 11:30 AM, Pierre Joye wrote:

> 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.

Bob Weinand

12 years ago

Am 22.10.2013 um 11:53 schrieb Sebastian Bergmann <sebastian@php.net>:

> On 10/22/2013 11:30 AM, Pierre Joye wrote:
>> 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.

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

Sebastian Bergmann

12 years ago

On 10/22/2013 12:08 PM, Bob Weinand wrote:

> 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.

Etienne Kneuss

12 years ago

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,

Zeev Suraski

12 years ago

> -----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
>
> On Mon, 21 Oct 2013, Bob Weinand wrote:
>
> > 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.

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

Bob Weinand

12 years ago

Am 22.10.2013 um 12:54 schrieb "Zeev Suraski" <zeev@zend.com>:

>> -----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
>>
>>> On Mon, 21 Oct 2013, Bob Weinand wrote:
>>>
>>> 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.
>
> 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...)

Derick Rethans

12 years ago

On Tue, 22 Oct 2013, Bob Weinand wrote:

> Am 22.10.2013 um 12:54 schrieb "Zeev Suraski" <zeev@zend.com>:
>
> > From: Derick Rethans [mailto:derick@php.net]
> > Sent: Tuesday, October 22, 2013 12:12 PM
> >
> >> On Mon, 21 Oct 2013, Bob Weinand wrote:
> >>>
> >>> 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.
> >
> > 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.
>
> 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

Bob Weinand

12 years ago

Am 22.10.2013 um 14:28 schrieb Derick Rethans <derick@php.net>:

> On Tue, 22 Oct 2013, Bob Weinand wrote:
>> Am 22.10.2013 um 12:54 schrieb "Zeev Suraski" <zeev@zend.com>:
>>
>>> From: Derick Rethans [mailto:derick@php.net]
>>> Sent: Tuesday, October 22, 2013 12:12 PM
>>>
>>>> On Mon, 21 Oct 2013, Bob Weinand wrote:
>>>>>
>>>>> 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.
>>>
>>> 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.
>>
>> 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.

I agree, but if people disagree, then I'd like to hear which code they'd prefer.

>> 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.

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

Zeev Suraski

12 years ago

> > 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...)

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

Julien Pauli

12 years ago

On Tue, Oct 22, 2013 at 10:40 PM, Zeev Suraski <zeev@zend.com> wrote:

> > > 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...)
>
> 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

Kevin Ingwersen

12 years ago

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 <jpauli@php.net>:

Stas Malyshev

12 years ago

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

Clint Priest

12 years ago

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.

On 10/22/2013 3:35 PM, Stas Malyshev wrote:

Guilherme Blanco

12 years ago

+1 on idea
-1 on implementation


On Tue, Oct 22, 2013 at 8:19 PM, Clint Priest <cpriest@php.net> wrote:

> 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.
>
>
> On 10/22/2013 3:35 PM, Stas Malyshev wrote:
>
>> 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.
>>
>
>

--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada