www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - RFC: Behavior of continue in do/while loops.

reply Downs <default_357-line yahoo.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just came upon the interesting fact that using the "continue"
statement in a do { } while() loop does not, in fact, continue with the
next loop, but instead continues with the _condition_.
I know this is the same behavior as in C, but as somebody who never
encountered it before I can assure you, it's highly unintuitive.
The confusion here stems largely from the way a do/while loop looks -
the condition is found at the _end_ at the loop body, yet I expected
continue to jump to the _beginning_.
There is two questions I want to ask:
First, if you were starting a new language, should the behavior of
continue in that language match what I expected in this case?
(theoretical case)
And second, should the behavior be changed in the D programming
language, even though it _might_ conceivably break code that relies on
the current behavior? (practical case)

Looking forward to your comments,
 --downs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG6AvvpEPJRr05fBERAnfQAJ0UapoxtHQCtIfTerkFe3iUnTHXtACfTFj4
ennSYblhmnx1yOzb6izeCfs=
=kBA4
-----END PGP SIGNATURE-----
Sep 12 2007
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Downs" wrote
 I just came upon the interesting fact that using the "continue"
 statement in a do { } while() loop does not, in fact, continue with the
 next loop, but instead continues with the _condition_.
 I know this is the same behavior as in C, but as somebody who never
 encountered it before I can assure you, it's highly unintuitive.
 The confusion here stems largely from the way a do/while loop looks -
 the condition is found at the _end_ at the loop body, yet I expected
 continue to jump to the _beginning_.
 There is two questions I want to ask:
 First, if you were starting a new language, should the behavior of
 continue in that language match what I expected in this case?
 (theoretical case)

My view of the continue statement is that it means "I am done with this iteration of the loop, skip to the next one." In that sense, I think the continue statement works correctly as it is implemented today. BTW, you could implement what you want by using an infinite loop and a break statement. i.e.: do { ... } while(condition) becomes: while(true) { ... if(condition) break; }
 And second, should the behavior be changed in the D programming
 language, even though it _might_ conceivably break code that relies on
 the current behavior? (practical case)

Nope :) Alienating C/Java developers is not a good idea. -Steve
Sep 12 2007
parent reply Downs <default_357-line yahoo.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steven Schveighoffer wrote:
 "Downs" wrote
 I just came upon the interesting fact that using the "continue"
 statement in a do { } while() loop does not, in fact, continue with the
 next loop, but instead continues with the _condition_.
 I know this is the same behavior as in C, but as somebody who never
 encountered it before I can assure you, it's highly unintuitive.
 The confusion here stems largely from the way a do/while loop looks -
 the condition is found at the _end_ at the loop body, yet I expected
 continue to jump to the _beginning_.
 There is two questions I want to ask:
 First, if you were starting a new language, should the behavior of
 continue in that language match what I expected in this case?
 (theoretical case)

My view of the continue statement is that it means "I am done with this iteration of the loop, skip to the next one." In that sense, I think the continue statement works correctly as it is implemented today. BTW, you could implement what you want by using an infinite loop and a break statement. i.e.: do { ... } while(condition) becomes: while(true) { ... if(condition) break; }

 
 And second, should the behavior be changed in the D programming
 language, even though it _might_ conceivably break code that relies on
 the current behavior? (practical case)

Nope :) Alienating C/Java developers is not a good idea. -Steve

1) forbidding continue in do/while and replacing it with continue do/continue while, or 2) adding goto do/goto while statements. The first one has the advantage of making it totally impossible for a newcomer to trip on this, while the second one has the advantage of not breaking existing code. Whaddya think? --downs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6BnJpEPJRr05fBERAsnFAJ4xcsAi5bkk5JRVa+lM/mv+kafurgCcCU0n /g7nchrjUCIBAW9+EpRgo/g= =TslT -----END PGP SIGNATURE-----
Sep 12 2007
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Downs" wrote
 Steven Schveighoffer wrote:
 Nope :)  Alienating C/Java developers is not a good idea.

 -Steve

1) forbidding continue in do/while and replacing it with continue do/continue while, or 2) adding goto do/goto while statements. The first one has the advantage of making it totally impossible for a newcomer to trip on this, while the second one has the advantage of not breaking existing code. Whaddya think?

I appreciate that you have issues with the continue statement, but I think they are very subtle, and very uncommon. That and the fact that precedence is to have continue re-evaluate the condition will likely result in the language not changing. I look at a do-while loop as a while loop that you want to execute at least once. The whole goal of it was to eliminate having to re-code the loop contents outside the loop so this would occur. What you want seems to me like a *restart* of the loop, not a *continuance*. I think making continue skip the condition is prone to more problems then it is worth (imagine someone switching a while loop to a do-while and then some kind of infinite loop occurs because there was a continue statement). I think adding syntax is not necessary since you can express your version of the loop easily with the current implementation. However, seeing as how I never use goto in my code, and there is precedence for using goto in other constructs (goto case, goto default), I have no problem with adding goto do (goto while is already handled by continue). But it's not up to me :) -Steve
Sep 12 2007
prev sibling next sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Downs wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 I just came upon the interesting fact that using the "continue"
 statement in a do { } while() loop does not, in fact, continue with the
 next loop, but instead continues with the _condition_.
 I know this is the same behavior as in C, but as somebody who never
 encountered it before I can assure you, it's highly unintuitive.
 The confusion here stems largely from the way a do/while loop looks -
 the condition is found at the _end_ at the loop body, yet I expected
 continue to jump to the _beginning_.
 There is two questions I want to ask:
 First, if you were starting a new language, should the behavior of
 continue in that language match what I expected in this case?
 (theoretical case)
 And second, should the behavior be changed in the D programming
 language, even though it _might_ conceivably break code that relies on
 the current behavior? (practical case)
 
 Looking forward to your comments,
  --downs
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFG6AvvpEPJRr05fBERAnfQAJ0UapoxtHQCtIfTerkFe3iUnTHXtACfTFj4
 ennSYblhmnx1yOzb6izeCfs=
 =kBA4
 -----END PGP SIGNATURE-----

I tend not to use do/while in favour of while and for loops myself so I hadn't really bumped into this behaviour nor needed to imagine what it might do. But, now that I know what it does, thinking about it, I reckon it's the correct (and intuitive - matter of opinion) thing for it to do and I don't think it should change. I suspect whether it is intuitive or not depends on how you think of 'continue', for example: However, if you think of 'continue' as meaning 'go to the next iteration' then you would expect it to do whatever it would have done at the end of this iteration, before the next one. If you think of 'continue' as meaning 'go back to the start of the(this?) loop' then you wouldn't expect the condition to be evaluated. I believe 'go to the next iteration' is the correct interpretation of 'continue'. In do/while, while and for to get from one iteration to the next you have to pass the condition. This is the contract/guarantee that the loop provides. Making the change you suggest will remove this guarantee, making it possible to go from iteration n to iteration n+1 without checking the condition. Despite the fact that the first iteration of do/while should be safe without the guarantee the 2nd-nth ones might not be, eg. if (*input != 0) { char *p = input; do { ..etc.. p++; ..etc.. continue; ..etc.. } while(*p != '\0'); } Regan
Sep 12 2007
parent reply Downs <default_357-line yahoo.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Regan Heath wrote
 I suspect whether it is intuitive or not depends on how you think of
 'continue', for example:

 However,  if you think of 'continue' as meaning 'go to the next
 iteration' then you would expect it to do whatever it would have done at
 the end of this iteration, before the next one.

 If you think of 'continue' as meaning 'go back to the start of
 the(this?) loop' then you wouldn't expect the condition to be evaluated.

The problem here is that for every case *but* a do/while loop, the two perspectives behave exactly the same. See my follow-up to the other post for a way to prevent this conflict.
 Regan

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6Bp5pEPJRr05fBERAuSBAKCLsmjUOiW/+xW+18EMOIs1v5bfkQCfTuvN r1q+L+5LTegmDMgs/V0/VlA= =JjXp -----END PGP SIGNATURE-----
Sep 12 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
Downs wrote:
 However,  if you think of 'continue' as meaning 'go to the next
 iteration' then you would expect it to do whatever it would have done at
 the end of this iteration, before the next one.

 If you think of 'continue' as meaning 'go back to the start of
 the(this?) loop' then you wouldn't expect the condition to be evaluated.

The problem here is that for every case *but* a do/while loop, the two perspectives behave exactly the same. See my follow-up to the other post for a way to prevent this conflict.

I don't agree, 'go back to the start of this loop' simply isn't what 'continue' does, in _any_ case. In all cases when you execute continue you move from iteration n to n+1. Moving from one iteration to the next _always_ involves checking the loop condition. The only difference between do/while and the other loops is that the 1st iteration is 'unprotected' by the guarantee of the loop condition. That's it. Expecting continue to 'go back to the start of this loop' is simply incorrect thinking. If you really want to 'go back to the start of this loop' you have to use goto. I don't really see the point in either of the solutions you have in the other thread, but then "it's not up to me". Regan
Sep 12 2007
parent reply Downs <default_357-line yahoo.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Regan Heath wrote:
 Downs wrote:
 However,  if you think of 'continue' as meaning 'go to the next
 iteration' then you would expect it to do whatever it would have done at
 the end of this iteration, before the next one.

 If you think of 'continue' as meaning 'go back to the start of
 the(this?) loop' then you wouldn't expect the condition to be evaluated.

The problem here is that for every case *but* a do/while loop, the two perspectives behave exactly the same. See my follow-up to the other post for a way to prevent this conflict.

I don't agree, 'go back to the start of this loop' simply isn't what 'continue' does, in _any_ case. In all cases when you execute continue you move from iteration n to n+1. Moving from one iteration to the next _always_ involves checking the loop condition.

My point was that it _behaves_ the same, as seen from the *outside*, leading to misunderstandings.
 
 The only difference between do/while and the other loops is that the 1st
 iteration is 'unprotected' by the guarantee of the loop condition.
 That's it.
 
 Expecting continue to 'go back to the start of this loop' is simply
 incorrect thinking.  If you really want to 'go back to the start of this
 loop' you have to use goto.

The problem is that because the two perspectives are so similar, *despite only one being technically correct*, it's easy to mistake the other one for the correct one if you learned coding by trial-and-error (as I did).
 
 I don't really see the point in either of the solutions you have in the
 other thread, but then "it's not up to me".

forcing the programmer to explicitly state what he wants, _independent of his perspective_. So even if he has the wrong idea of how continue actually works (as I did), he'll still be able to get the behavior he expected.
 
 Regan

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6DSkpEPJRr05fBERAuF9AJ4xNOlwp2b6EkLEH1QFHdZ7Fs3oogCeLLog zzpqAwdpoZujDL6HgoOh+Wo= =wGHk -----END PGP SIGNATURE-----
Sep 12 2007
parent Regan Heath <regan netmail.co.nz> writes:
Downs wrote:
 Regan Heath wrote:
 Downs wrote:
 However,  if you think of 'continue' as meaning 'go to the next
 iteration' then you would expect it to do whatever it would have done at
 the end of this iteration, before the next one.
 If you think of 'continue' as meaning 'go back to the start of
 the(this?) loop' then you wouldn't expect the condition to be evaluated.

perspectives behave exactly the same. See my follow-up to the other post for a way to prevent this conflict.

I don't agree, 'go back to the start of this loop' simply isn't what 'continue' does, in _any_ case. In all cases when you execute continue you move from iteration n to n+1. Moving from one iteration to the next _always_ involves checking the loop condition.

I know that's not what it _does_, but that wasn't my point. My point was that it _behaves_ the same, as seen from the *outside*, leading to misunderstandings.

I still don't agree that it "_behaves_ the same, as seen from the *outside*" but I wont labour the point. Regan
Sep 13 2007
prev sibling next sibling parent 0ffh <spam frankhirsch.net> writes:
Hi, downs!

Hmmm, I don't think the behaviour as-is is counterintuitive,
but that's a matter of individual preconditioning, I gather.

Also, the instances of me using the do...while construct are
few and far between, because I consider it looks rather ugly
and seldom find myself in a situation where I'd be forced to
use it (read: where it'd make the code better :-).

Regards, Frank
Sep 12 2007
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Downs" wrote
 The confusion here stems largely from the way a do/while loop looks -
 the condition is found at the _end_ at the loop body, yet I expected
 continue to jump to the _beginning_.

BTW, usually the compiler re-arranges a while loop so that the condition is at the end also. Looks something like this: while(condition) { ... } becomes JMP loop loopstart: ... loop: TST condition ; sets zero flag if condition is true JNZ loopstart Actually, I have no idea how to code in assembly, so my code is probably worthless, but you get the idea :) -Steve
Sep 12 2007
prev sibling next sibling parent renoX <renosky free.fr> writes:
Downs a écrit :
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 I just came upon the interesting fact that using the "continue"
 statement in a do { } while() loop does not, in fact, continue with the
 next loop, but instead continues with the _condition_.

Yes, that's what I would expect.
 I know this is the same behavior as in C, but as somebody who never
 encountered it before I can assure you, it's highly unintuitive.

Bah, a matter of opinion, I interpret 'continue' as 'continue to the end', why would 'continue to the beginning' more intuitive?
 The confusion here stems largely from the way a do/while loop looks -
 the condition is found at the _end_ at the loop body, yet I expected
 continue to jump to the _beginning_.

But even in a for loop, continue doesn't really continue to the beginning of the loop, it continue to the 'termination test'.
 There is two questions I want to ask:
 First, if you were starting a new language, should the behavior of
 continue in that language match what I expected in this case?
 (theoretical case)

No, current continue behaviour is consistent for while/for/do .. while which is good. Maybe a different keyword could be more intuitive, but I can't find any (skip has the same issue, goto_end is not clear if it's break or continue, etc) unless you want to start using keyword like continue_to_end_of_iteration..
 And second, should the behavior be changed in the D programming
 language, even though it _might_ conceivably break code that relies on
 the current behavior? (practical case)

No: 1) the continue behaviour is coherent. 2) it's consistent with C's behaviour. There are many thing that I dislike in C (stupid variable declaration syntax, use of && for shortcut-and instead of & even though shortcut-and are much more used than binary-and, use 0 to start octal instead of 0o ,etc) but continue isn't one of these (except that it should take a 'loop label' as an optional argument as D's continue does). renoX
 
 Looking forward to your comments,
  --downs
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFG6AvvpEPJRr05fBERAnfQAJ0UapoxtHQCtIfTerkFe3iUnTHXtACfTFj4
 ennSYblhmnx1yOzb6izeCfs=
 =kBA4
 -----END PGP SIGNATURE-----

Sep 12 2007
prev sibling next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Downs wrote

 First, if you were starting a new language, should the behavior of
 continue in that language match what I expected in this case?
 (theoretical case)

No. According to your introduction you might have entangled yourself by trying to optimize away a loop nested in another loop: do{ do{ }while( ); }while( ); -manfred
Sep 12 2007
parent reply Downs <default_357-line yahoo.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manfred Nowak wrote:
 Downs wrote
 
 First, if you were starting a new language, should the behavior of
 continue in that language match what I expected in this case?
 (theoretical case)

No. According to your introduction you might have entangled yourself by trying to optimize away a loop nested in another loop: do{ do{ }while( ); }while( ); -manfred

special-case logic for 1.1 chunks in a 1.0 loop along the lines of do { receive; if (isChunked) { if (chunkedDownloading) continue; break; } } while (notReceivedEnough) so I expected the continue to restart the loop, but it executed the condition (which naturally failed abysmally, because I wasn't doing a normal download :) Doesn't matter, it works now. --downs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6E+JpEPJRr05fBERAp4bAJ9W/K15qgbpPg+P301+rBNeKC/PcACgkVgj 6N0xl0ARvyd5pqcc8kBWKlc= =YDS2 -----END PGP SIGNATURE-----
Sep 12 2007
next sibling parent reply BCS <BCS pathlink.com> writes:
Downs wrote:
 do {
 	receive;
 	if (isChunked) {
 		if (chunkedDownloading) continue;
 		break;
 	}
 } while (notReceivedEnough)

I think this will get you the same result do { receive; } while (isChunked && chunkedDownloading && notReceivedEnough)
Sep 12 2007
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"BCS" <BCS pathlink.com> wrote in message 
news:fc9kjm$28pv$1 digitalmars.com...
 Downs wrote:
 do {
 receive;
 if (isChunked) {
 if (chunkedDownloading) continue;
 break;
 }
 } while (notReceivedEnough)

I think this will get you the same result do { receive; } while (isChunked && chunkedDownloading && notReceivedEnough)

I think it needs to be: while(isChunked && chunkedDownloading || !isChunked && notReceivedEnough) -Steve
Sep 12 2007
parent BCS <ao pathlink.com> writes:
Reply to Steven,

 "BCS" <BCS pathlink.com> wrote in message
 news:fc9kjm$28pv$1 digitalmars.com...
 
 Downs wrote:
 
 do {
 receive;
 if (isChunked) {
 if (chunkedDownloading) continue;
 break;
 }
 } while (notReceivedEnough)

do { receive; } while (isChunked && chunkedDownloading && notReceivedEnough)

while(isChunked && chunkedDownloading || !isChunked && notReceivedEnough) -Steve

silly me. I used the current semantics, not what he was looking for.
Sep 12 2007
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Downs wrote
 do {
      receive;
      if (isChunked) {
           if (chunkedDownloading) continue;
           break;
      }
 } while (notReceivedEnough)

... more entangled than I thought :-) -manfred
Sep 12 2007
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Wed, 12 Sep 2007 17:55:27 +0200, Downs wrote:

 There is two questions I want to ask:
 First, if you were starting a new language, should the behavior of
 continue in that language match what I expected in this case?
 (theoretical case)

Yes.
 And second, should the behavior be changed in the D programming
 language, even though it _might_ conceivably break code that relies on
 the current behavior? (practical case)

No. However, if the introduction of scoped-labels is made, this becomes a simple goto issue. do { top: . . . if (whatever) goto top; . . . } while( some_condition); do { top: . . . if (anothertest) goto top; . . . } while( some_other_condition); At the moment, the scope of labels is too large and you have to invent new label identifiers for each block scope. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Sep 12 2007