[RFC] Loop... or...

10 years ago by Leigh — view source

unread

Hello list!

This is an item that has been repeatedly requested in various forms,
with no solid implementation to back it up, yet remaining quite
desirable to the developer community at large.

Loops with a default block, executed in the event that the loop is
never entered.

https://wiki.php.net/rfc/loop_or

Traditionally this is requested as a loop {} else {} structure,
however due to the choice of keyword this causes significant BC
problems.

I have written an RFC presenting this feature as loop {} or {} along
with how I intend to implement it. I have consulted with several core
contributors as well as normal developers, and this seems to be the
most BC-complete option.

A poll of local developers indicates a strong positive response
supporting this feature, so please take the time to consider and
discuss what is laid out in the RFC, as many of us would like this to
become a permanent fixture of the language.

I especially need input regarding Opcache concerns, as this is not an
area of expertise for me.

I will be developing the patch myself, and hope to have a full proof
of concept completed by the end of this weekend. (for and while are
both working, foreach currently segfaults, I am working on it)

Thanks for reading.

Leigh.

10 years ago by Rowan Collins — view source

unread

Hello list!

This is an item that has been repeatedly requested in various forms,
with no solid implementation to back it up, yet remaining quite
desirable to the developer community at large.

Loops with a default block, executed in the event that the loop is
never entered.

https://wiki.php.net/rfc/loop_or

Interesting! Not sure I've ever felt the need for it, but it seems like
it could be quite handy to have in the toolbox, as it were.

It's worth noting that both Smarty and Twig implement a similar
mechanism in their respective foreach loop syntax.

Smarty spells it {foreachelse}
http://www.smarty.net/docs/en/language.function.foreach.tpl

Twig spells it {% else %}
http://twig.sensiolabs.org/doc/tags/for.html#the-else-clause

--
Rowan Collins
[IMSoP]

10 years ago by Leigh — view source

unread

It's worth noting that both Smarty and Twig implement a similar mechanism in
their respective foreach loop syntax.

Smarty spells it {foreachelse}
http://www.smarty.net/docs/en/language.function.foreach.tpl

Twig spells it {% else %}
http://twig.sensiolabs.org/doc/tags/for.html#the-else-clause

--
Rowan Collins

Yep, I thought I included a paragraph about templating engines
emulating this, but I probably did a copy/edit/paste fail --> on the
todo list for next edit.

10 years ago by Andrea Faulds — view source

unread

Loops with a default block, executed in the event that the loop is
never entered.

https://wiki.php.net/rfc/loop_or

While this might be useful, I’d prefer we copy Python’s else behaviour, where a block of code is executed when break is never used. This feature makes code that does, for example, a linear search nicer to read.

--
Andrea Faulds
http://ajf.me/

10 years ago by Leigh — view source

unread

While this might be useful, I’d prefer we copy Python’s else behaviour, where a block of code is executed when break is never used. This feature makes code that does, for example, a linear search nicer to read.

--
Andrea Faulds
http://ajf.me/

Hey Andrea,

The RFC describes in particular why the else keyword is a bad choice,
and opens up the possibility of Python-style "else" in a future RFC.
Please consider this feature request as independent of any
python-related functionality.

I understand the desire for something python-like, however it
certainly doesn't fall under the "or" keyword. If anything we could
probably get away with it under "and", or introduce a new keyword of
"then", but really, that is a subject for a different thread
altogether. This thread is about the "loop not entered" syntax. Lets
stick to that for now, and I'm more than happy to create a thread for
the other scenario later on, and we can discuss the python style there
instead.

Cheers,

Leigh.

10 years ago by Andrea Faulds — view source

unread

I understand the desire for something python-like, however it
certainly doesn't fall under the "or" keyword.

Why not? Python uses “else”, and before creating this RFC you initially wanted to use “else”.

If anything we could
probably get away with it under "and", or introduce a new keyword of
"then", but really, that is a subject for a different thread
altogether. This thread is about the "loop not entered" syntax. Lets
stick to that for now, and I'm more than happy to create a thread for
the other scenario later on, and we can discuss the python style there
instead.

I’m bringing it up because I think we’re only going to end up with one feature or the other, and I think Python’s behaviour is more useful.

--
Andrea Faulds
http://ajf.me/

10 years ago by Leigh — view source

unread

Why not? Python uses “else”, and before creating this RFC you initially wanted to use “else”.

Then I realised it was folly. Documented in the RFC why "else" is a bad choice.

I’m bringing it up because I think we’re only going to end up with one feature or the other, and I think Python’s behaviour is more useful.

We can absolutely have both, but it's not for this RFC.

10 years ago by Leigh — view source

unread

Updated RFC to include information about templating engines often
emulating this behaviour for ease-of-use.

Changed target version to be specifically PHP 7, so that it's clear
that changes target the AST based compiler. (If there's ever a 5.next,
we can consider that at the time)

10 years ago by Sara Golemon — view source

unread

https://wiki.php.net/rfc/loop_or

I like the general idea, but rather than explicitly focusing on the 'or' keyword, how about just giving all loop constructs (do/while/for/foreach) a return value? I'd suggest an integer return value indicating the number of times the loop executed.

This accomodates your use case since foreach(...) {} or { defaultblock } still works, while also allowing for others:

e.g.:
$ranTwice = foreach(...) {} == 2;

It does introduce a temp var, but OpCache+ can trivially optimize that out when it isn't used.

-Sara

10 years ago by Leigh — view source

unread

I like the general idea, but rather than explicitly focusing on the 'or' keyword, how about just giving all loop constructs (do/while/for/foreach) a return value? I'd suggest an integer return value indicating the number of times the loop executed.

This accomodates your use case since foreach(...) {} or { defaultblock } still works, while also allowing for others:

e.g.:
$ranTwice = foreach(...) {} == 2;

It does introduce a temp var, but OpCache+ can trivially optimize that out when it isn't used.

-Sara

Sorry @Sara - didn't reply to all the first time.

mind === blown

This would open up a huge amount of other functionality I'd never
dreamed of (some of which is quite scary!)

for($i = for(...) {}; $i < ...) {}

I'm really not sure I understand the full implication of this though.
This would mean changing loop constructs from statements to
expressions. I wonder how difficult that will actually be, and what
other problems it would cause (I obviously haven't played with this
idea yet).

It would also mean having to make { default block } into an
expression... with a return value (to be allowed on either side of the
boolean or)

Lots to think about here, if it's at all viable this will need it's
own separate RFC, it's a much more invasive change, but definitely a
great idea.

10 years ago by Leigh — view source

unread

Lots to think about here, if it's at all viable this will need it's
own separate RFC, it's a much more invasive change, but definitely a
great idea.

NikiC and Bob have convinced me to carry on with the original
proposal, and bring up Saras ideas as another RFC afterwards, so the
full impact of converting loops to expressions can be judged on its
own merits. It is BC with this RFC, so no problem there.

10 years ago by Sara Golemon — view source

unread

Lots to think about here, if it's at all viable this will need it's
own separate RFC, it's a much more invasive change, but definitely a
great idea.

NikiC and Bob have convinced me to carry on with the original
proposal, and bring up Saras ideas as another RFC afterwards, so the
full impact of converting loops to expressions can be judged on its
own merits. It is BC with this RFC, so no problem there.

Agreed. If we do find a nice way to make loops into expressions and
make default blocks work with that, then the explicit LOOP/OR syntax
can vanish and work implicitly with the expression approach.

-Sara

10 years ago by Leigh — view source

unread

Completed my proof of concept patch:
https://github.com/lt/php-src/compare/loop-or

This gives for, foreach, and while loops an additional "or {}" block

10 years ago by Christian Stoller — view source

unread

From: Leigh [mailto:leight@gmail.com] Sent: Friday, September 19, 2014 11:57 PM

Traditionally this is requested as a loop {} else {} structure,
however due to the choice of keyword this causes significant BC
problems.

I have written an RFC presenting this feature as loop {} or {} along
with how I intend to implement it. I have consulted with several core
contributors as well as normal developers, and this seems to be the
most BC-complete option.

I like this proposal as I am using this feature in Twig very often.
But I would really prefer using "else" instead of "or", because it
is already common in the mentioned projects.
Maybe you could reconsider if it is really not possible to use "else".

What about making the brackets for the loop block obligatory for
using this feature?

Christian

10 years ago by Leigh — view source

unread

I like this proposal as I am using this feature in Twig very often.
But I would really prefer using "else" instead of "or", because it
is already common in the mentioned projects.
Maybe you could reconsider if it is really not possible to use "else".

It's really not possible to use "else" without a huge BC break in
one form or another, something I'm trying to avoid at all costs.

What about making the brackets for the loop block obligatory for
using this feature?

Unfortunately that wouldn't help, we'd have to enforce braces on
everything (if/else/elseif/while/for/etc) to make it possible to hang
an "else" on the bottom of a loop, again a pretty big BC break.

I have actually discussed "braces everywhere" with several internals
devs, and the response has been pretty much unanimous: We'd like it,
but it will never pass the vote. It would be trivial to provide a
migration script though. Feel free to test the water with this idea ;)

10 years ago by Xinchen Hui — view source

unread

Hey:

Hello list!

This is an item that has been repeatedly requested in various forms,
with no solid implementation to back it up, yet remaining quite
desirable to the developer community at large.

Loops with a default block, executed in the event that the loop is
never entered.

https://wiki.php.net/rfc/loop_or

Traditionally this is requested as a loop {} else {} structure,
however due to the choice of keyword this causes significant BC
problems.

I have written an RFC presenting this feature as loop {} or {} along
with how I intend to implement it. I have consulted with several core
contributors as well as normal developers, and this seems to be the
most BC-complete option.

A poll of local developers indicates a strong positive response
supporting this feature, so please take the time to consider and
discuss what is laid out in the RFC, as many of us would like this to
become a permanent fixture of the language.

I especially need input regarding Opcache concerns, as this is not an
area of expertise for me.

I will be developing the patch myself, and hope to have a full proof
of concept completed by the end of this weekend. (for and while are
both working, foreach currently segfaults, I am working on it)

Thanks for reading.

Leigh.
Maybe I am too conservative. I don't like this idea......... :<

And I DO THINK, we should try to stop brings lots of new things into PHP7.

I am worring whether it can be release in the next year....

thanks

--

--
Xinchen Hui
@Laruence
http://www.laruence.com/

10 years ago by Leigh — view source

unread

Maybe I am too conservative. I don't like this idea......... :<

And I DO THINK, we should try to stop brings lots of new things into PHP7.

I am worring whether it can be release in the next year....

Can you give some more details on why you don't like the idea? Is
there anything I can do to the proposal to make it more acceptable?

I don't think you should worry this postponing the release. I plan to
do all of the work for this, it shouldn't cost you any time at all
except a few lines about your opinion.

I'm not comfortable deep diving into the core, so it's not like I can
help make the release go faster if I stop work on this.

10 years ago by Leigh — view source

unread

If there are no outstanding issues raised by tonight (UTC), I will
open this RFC up to a vote.

I'd like to remind everyone that we're discussing and voting on the
concept here rather than the implementation. I'm personally not happy
with "or", but if there is enough support during voting then I am
happy to actively work on finding the best solution (and maybe a
second round of voting when we have all of the possibilities lined
up), if there is no support then I wont spend time on it.

Thanks,

Leigh.

10 years ago by Andrea Faulds — view source

unread

If there are no outstanding issues raised by tonight (UTC), I will
open this RFC up to a vote.

I'd like to remind everyone that we're discussing and voting on the
concept here rather than the implementation. I'm personally not happy
with "or", but if there is enough support during voting then I am
happy to actively work on finding the best solution (and maybe a
second round of voting when we have all of the possibilities lined
up), if there is no support then I wont spend time on it.

Huh, why is the keyword choice not part of the vote? So, if people vote for it with ‘or’, you could change it to something completely different?

I don’t think that’s normal procedure.

--
Andrea Faulds
http://ajf.me/

10 years ago by Leigh — view source

unread

Huh, why is the keyword choice not part of the vote? So, if people vote for it with ‘or’, you could change it to something completely different?

I don’t think that’s normal procedure.

Because there currently isn't a choice.

10 years ago by Rowan Collins — view source

unread

I certainly don't see (a) and (f) as being at all mutually exclusive.

Sorry, that was meant to say (a) and (e). Or, in plain English, I don't
see why we couldn't have both Smarty-style "if the loop executed zero
times" and Python-style "if the break keyword wasn't used to end the
loop early", as long as we can think of keywords for them.

--
Rowan Collins
[IMSoP]

10 years ago by Leigh — view source

unread

It seems like there are actually quite a number of special blocks you
could define, such as:

a) When the body is executed zero times (proposed "or" block)
b) When the body is executed exactly once (in a do...while loop, as
mentioned in the RFC)
c) After every iteration of the loop, even if the iteration was ended early
(Perl's "continue" block [1], where "next" is equivalent to PHP's
"continue")
d) After every iteration of the loop, only if the iteration was ended
early (would have a similar relationship to (c) as "catch" does to
"finally")
e) After the end of the loop, if "break" was not used (Python's "else" block
[2])
f) After the end of the loop, if "break" WAS used

Some or all of these can be implemented (in other RFCs).

However in order to avoid specifying every permutation in the grammar
it would require converting loop structures that currently have a
defined number of children, into list structures ("if" behaves like
this, with multiple optional "elseifs" and an optional "else").

Obviously the complexity increases with each new type of block but I
think the type being addressed in this RFC, and the python-style type
can live side-by-side pretty happily. So, lets deal with this one
first, and then I will work on a python-style one afterwards (promise)

10 years ago by Rowan Collins — view source

unread

On 20 September 2014 01:02, Rowan Collins rowan.collins@gmail.com
wrote:

It seems like there are actually quite a number of special blocks you
could define

Some or all of these can be implemented (in other RFCs).

However in order to avoid specifying every permutation in the grammar
it would require converting loop structures that currently have a
defined number of children, into list structures ("if" behaves like
this, with multiple optional "elseifs" and an optional "else").

Yeah, I absolutely didn't mean that all of these were equally essential, I was just brainstorming some of the possible permutations.

I guess the only way to avoid running out of keywords would be to have a generic clause like "on(x)", but that's probably just asking for trouble...

foreach ( $x as $y ) {
...
} on ( break ) {
...
} on ( nobreak ) {
...
} on ( continue ) {
...
} on ( nocontinue ) {
...
} on ( noloop ) {
...
} on ( loopcount == 1 ) {
...
}

Yeah, let's not do that! :p

Rowan Collins
[IMSoP]

10 years ago by Sara Golemon — view source

unread

I like the general idea, but rather than explicitly focusing on the 'or' keyword, how about just giving all loop constructs (do/while/for/foreach) a return value? I'd suggest an integer return value indicating the number of times the loop executed.

mind === blown

This would open up a huge amount of other functionality I'd never
dreamed of (some of which is quite scary!)

for($i = for(...) {}; $i < ...) {}

Yikes, I truly hope nobody ever writes that code. Ever.

I'm really not sure I understand the full implication of this though.
This would mean changing loop constructs from statements to
expressions. I wonder how difficult that will actually be, and what
other problems it would cause (I obviously haven't played with this
idea yet).

I admit, I haven't thought it through entirely either. Nor even if
it's definitely possible.

It would also mean having to make { default block } into an
expression... with a return value (to be allowed on either side of the
boolean or)

Excellent point, a block only works with T_OR if it has a value. I'm
pretty sure that at this point, it doesn't. That does put a monkey
wrench into it. Perhaps a lambda could accommodate that? Starts to
get ugly though...

Lots to think about here, if it's at all viable this will need it's
own separate RFC, it's a much more invasive change, but definitely a
great idea.

Yeah, I might be trying too hard. Worth exploring a tiny bit though...

-Sara

10 years ago by Patrick Schaaf — view source

unread

Am 21.09.2014 02:22 schrieb "Sara Golemon" pollita@php.net:

It would also mean having to make { default block } into an
expression... with a return value (to be allowed on either side of the
boolean or)

Excellent point, a block only works with T_OR if it has a value. I'm
pretty sure that at this point, it doesn't. That does put a monkey
wrench into it. Perhaps a lambda could accommodate that? Starts to
get ugly though...

This strongly reminds me of statement expressions in GCC. Any block used in
an expression context, would evaluate to the last expression result
executed computed within the block.

Any code using such constructs, quickly becomes a totally unreadable mess.
GCC gets away with that because the whole thing, as far as I remember and
have seen in practise, is meant to be used within CPP macros, i.e. hidden
at the call sites. And PHP lacking a CPP macro concept, that excuse is not
present for us.

So,, to complete this great idea, we need to add a CPP macro like facility,
too :)

best regards
Patrick

10 years ago by Michael Wallner — view source

unread

I like the general idea, but rather than explicitly focusing on
the 'or' keyword, how about just giving all loop constructs
(do/while/for/foreach) a return value? I'd suggest an integer
return value indicating the number of times the loop executed.

mind === blown

This would open up a huge amount of other functionality I'd never
dreamed of (some of which is quite scary!)

for($i = for(...) {}; $i < ...) {}

Yikes, I truly hope nobody ever writes that code. Ever.

I'm really not sure I understand the full implication of this
though. This would mean changing loop constructs from statements
to expressions. I wonder how difficult that will actually be, and
what other problems it would cause (I obviously haven't played with
this idea yet).

I admit, I haven't thought it through entirely either. Nor even if
it's definitely possible.

It would also mean having to make { default block } into an
expression... with a return value (to be allowed on either side of
the boolean or)

Excellent point, a block only works with T_OR if it has a value.
I'm pretty sure that at this point, it doesn't. That does put a
monkey wrench into it. Perhaps a lambda could accommodate that?
Starts to get ugly though...

Lots to think about here, if it's at all viable this will need
it's own separate RFC, it's a much more invasive change, but
definitely a great idea.

Yeah, I might be trying too hard. Worth exploring a tiny bit
though...

-Sara

Actually, I once or twice wanted to use while() {} else {} instead of
wrapping the loop in an "if". The extended version of Sara, while
looking great at a first glance, quickly turns into a crazy nightmare
after looking at the points already cooked up :)

--
Regards,
Mike