Loop exit
-
Running into a feature-by-feature language comparison made me think back of a feature I saw in one single langugage, but would fit very nicely into a lot of the pascal/c/java/... class of languages: Alternate loop exits. When iterating through a list, an array or some sort of collection, objects are not all treated equally: You reach a sentinel, find the object you're searching for, reach the capacity of the bucket you are filling up, or whatever. The job has successfully been done, so you exit the loop. Or, you do not complete the job: There is no sentinel (because the buffer is completely filled), the desired object is not found, or the bucket has still some capacitly left. Running through the collection to the end or not running to the end are different situations, frequently requiring different handling. In most languages, an early exit requires that you set some boolean flag decleared outside the loop, then break (or whatever the keyword is in your favorite language), and after the loop you add an if-statement, syntactically detached from the loop, to provide differnt treatment based on the setting of the flag. I was programming in this language called Planc - "Programming LANguage for Nord Computers", a vendor specific systems implementation - remmebered by noone today. It had this nice syntactic sugar:
for listpointer in listhead:nextfield do ... processing list element as desired while listpointer.keyvalue <> desidred\_key ... porcessing list element as desired exitwhile ... the desired list element was found, write("list element was found and processed") exitfor ... reached end of list without finding the desired element write("no element with the desired key was found in the list") endforNo need for any one-time-use bool cluttering up variable space. No need to introduce a separate block for testing and breaking out. No need for a detached if-statement - the different loop exit handling is syntactically integrated with the loop itself. I never saw this sort of construct in any other language, but I have been missing it hundred of times. Are there other languages out there with something similar? Certainly not C, C++, Java, C#, Pascal, ... And, by the way: The above specification of the iteration is a nice syntactic sugar for what would be in C-like languages:
for (listptrtype listpointer = listhead; listpointer != null; listpointer =
Visual Basic.NET supports similar constructs, such as:
Exit For
Exit While
Exit Doand continuations like:
Continue For
Continue While
Continue Do -
After reading the original post again, I wasn't sure I got it right, so I had a look in wikipedia about PLANC. Now I think EXITFOR specifies what to do if the for loop exits normally and the EXITWHILE specifies what to do when a WHILE clause (one of many) becomes true. Both blocks are specified inside the loop. So I see a WHILE in PLANC as a "if() break;" construction in c. And EXITFOR and EXITWHILE would be coded as something like if (got_out_with_break) {// EXITWHILE block} else {// EXITFOR block} but I could be wrong :) As stated below - Python got it as well.
After reading the python remark below I think I've got it (good thing you pointed that out! :thumbsup:) I'm not quite convinced of the benefits though. It may indeed - as the OP stated - safe you an extra
ifor flag variable. But the price you pay is readability: the conditional code can be in an entirely different place than the condition, with potentially a lot of code in between. Even worse, after reading over the OP again, it seems like there can be severalwhilestatements that can all trigger the sameexitwhile, meaning that there can be several conditons that are all in different places, separated from the conditional code and the other conditions as well! How on earth are you supposed to keep track of the flow of control in code like that? :confused: There may be cases where such a language construct may make sense, and even be better readable than the alternatives offered in C and other languages. But I sense a great potential of abuse, and I suspect it takes both experience and sense of responsibility to use it well. Should a programming language support such a feature? If you say "yes", will you also agree that cars should be allowed to use the sidewalks (provided they are wide enough)?. These are the same questions! So, the answer is also the same: we cannot assume that people will use that option responsibly, so we're better off without it!GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
Running into a feature-by-feature language comparison made me think back of a feature I saw in one single langugage, but would fit very nicely into a lot of the pascal/c/java/... class of languages: Alternate loop exits. When iterating through a list, an array or some sort of collection, objects are not all treated equally: You reach a sentinel, find the object you're searching for, reach the capacity of the bucket you are filling up, or whatever. The job has successfully been done, so you exit the loop. Or, you do not complete the job: There is no sentinel (because the buffer is completely filled), the desired object is not found, or the bucket has still some capacitly left. Running through the collection to the end or not running to the end are different situations, frequently requiring different handling. In most languages, an early exit requires that you set some boolean flag decleared outside the loop, then break (or whatever the keyword is in your favorite language), and after the loop you add an if-statement, syntactically detached from the loop, to provide differnt treatment based on the setting of the flag. I was programming in this language called Planc - "Programming LANguage for Nord Computers", a vendor specific systems implementation - remmebered by noone today. It had this nice syntactic sugar:
for listpointer in listhead:nextfield do ... processing list element as desired while listpointer.keyvalue <> desidred\_key ... porcessing list element as desired exitwhile ... the desired list element was found, write("list element was found and processed") exitfor ... reached end of list without finding the desired element write("no element with the desired key was found in the list") endforNo need for any one-time-use bool cluttering up variable space. No need to introduce a separate block for testing and breaking out. No need for a detached if-statement - the different loop exit handling is syntactically integrated with the loop itself. I never saw this sort of construct in any other language, but I have been missing it hundred of times. Are there other languages out there with something similar? Certainly not C, C++, Java, C#, Pascal, ... And, by the way: The above specification of the iteration is a nice syntactic sugar for what would be in C-like languages:
for (listptrtype listpointer = listhead; listpointer != null; listpointer =
But if you had for (...) { for (...) { I want to exitfor from the outer loop from a condition in the inner loop } } How would you do it? goto was invented for a reason and this is it!!! :-D
-
Visual Basic.NET supports similar constructs, such as:
Exit For
Exit While
Exit Doand continuations like:
Continue For
Continue While
Continue DoIn fact I seem to remember an "exit for" in QBASIC. Loop exits go way back in many BASIC compliers. But all you C# coders don't worry; you're still "the best". You'll become better coders as C# becomes more like BASIC. :wtf: LOL, sorry couldn't help myself. :-O
- great coders make code look easy - When humans are doing things computers could be doing instead, the computers get together late at night and laugh at us. - ¿Neal Ford?
-
Running into a feature-by-feature language comparison made me think back of a feature I saw in one single langugage, but would fit very nicely into a lot of the pascal/c/java/... class of languages: Alternate loop exits. When iterating through a list, an array or some sort of collection, objects are not all treated equally: You reach a sentinel, find the object you're searching for, reach the capacity of the bucket you are filling up, or whatever. The job has successfully been done, so you exit the loop. Or, you do not complete the job: There is no sentinel (because the buffer is completely filled), the desired object is not found, or the bucket has still some capacitly left. Running through the collection to the end or not running to the end are different situations, frequently requiring different handling. In most languages, an early exit requires that you set some boolean flag decleared outside the loop, then break (or whatever the keyword is in your favorite language), and after the loop you add an if-statement, syntactically detached from the loop, to provide differnt treatment based on the setting of the flag. I was programming in this language called Planc - "Programming LANguage for Nord Computers", a vendor specific systems implementation - remmebered by noone today. It had this nice syntactic sugar:
for listpointer in listhead:nextfield do ... processing list element as desired while listpointer.keyvalue <> desidred\_key ... porcessing list element as desired exitwhile ... the desired list element was found, write("list element was found and processed") exitfor ... reached end of list without finding the desired element write("no element with the desired key was found in the list") endforNo need for any one-time-use bool cluttering up variable space. No need to introduce a separate block for testing and breaking out. No need for a detached if-statement - the different loop exit handling is syntactically integrated with the loop itself. I never saw this sort of construct in any other language, but I have been missing it hundred of times. Are there other languages out there with something similar? Certainly not C, C++, Java, C#, Pascal, ... And, by the way: The above specification of the iteration is a nice syntactic sugar for what would be in C-like languages:
for (listptrtype listpointer = listhead; listpointer != null; listpointer =
BASIC provides several exit statements such as EXIT LOOP EXIT FOR You can also set the condition in the call to the loop WHILE Not [answer you want is found] ... WEND will exit when the condition is met (of course you have to add another exit test to avoid infinite loops :) There are a bunch of similar constructs. To use this with some OOP type language just write a little function in BASIC (Visual Studio, PowerBasic), compile to a DLL and call it from the object you need to use. Visual Studio would probably let you do it all in the same project but then you wouldn't have the DLL to reuse.
-
Running into a feature-by-feature language comparison made me think back of a feature I saw in one single langugage, but would fit very nicely into a lot of the pascal/c/java/... class of languages: Alternate loop exits. When iterating through a list, an array or some sort of collection, objects are not all treated equally: You reach a sentinel, find the object you're searching for, reach the capacity of the bucket you are filling up, or whatever. The job has successfully been done, so you exit the loop. Or, you do not complete the job: There is no sentinel (because the buffer is completely filled), the desired object is not found, or the bucket has still some capacitly left. Running through the collection to the end or not running to the end are different situations, frequently requiring different handling. In most languages, an early exit requires that you set some boolean flag decleared outside the loop, then break (or whatever the keyword is in your favorite language), and after the loop you add an if-statement, syntactically detached from the loop, to provide differnt treatment based on the setting of the flag. I was programming in this language called Planc - "Programming LANguage for Nord Computers", a vendor specific systems implementation - remmebered by noone today. It had this nice syntactic sugar:
for listpointer in listhead:nextfield do ... processing list element as desired while listpointer.keyvalue <> desidred\_key ... porcessing list element as desired exitwhile ... the desired list element was found, write("list element was found and processed") exitfor ... reached end of list without finding the desired element write("no element with the desired key was found in the list") endforNo need for any one-time-use bool cluttering up variable space. No need to introduce a separate block for testing and breaking out. No need for a detached if-statement - the different loop exit handling is syntactically integrated with the loop itself. I never saw this sort of construct in any other language, but I have been missing it hundred of times. Are there other languages out there with something similar? Certainly not C, C++, Java, C#, Pascal, ... And, by the way: The above specification of the iteration is a nice syntactic sugar for what would be in C-like languages:
for (listptrtype listpointer = listhead; listpointer != null; listpointer =
Delphi's version of Pascal has Break (quit the loop) and Continue (begin the next iteration).
-
Delphi's version of Pascal has Break (quit the loop) and Continue (begin the next iteration).
-
But if you had for (...) { for (...) { I want to exitfor from the outer loop from a condition in the inner loop } } How would you do it? goto was invented for a reason and this is it!!! :-D
CHILL has a very nice solution to this: Every block, whether a procedure, loop, switch or even a linear sequence of statements enclosed with BEGIN and END, could be prefixed with a label. In CHILL, a label does not identify a point in the program, but a block, and consequently label scopes could be nested. So to leave the outer loop, you would write
OuterLoop:
DO FOR (...)InnerLoop:
DO FOR (...)
...
IF THEN EXIT InnerLoop; FI;
...
IF THEN EXIT OuterLoop; FI
...
ODOD
(Here I illustrate both leaving the inner loop and the outer loop.) However, CHILL doesn't provide what I asked for in my original post: If the post-loop processing depends on whether you completed the loop or left prematurely by EXIT, you must set some variable to a magic value and test it after the loop, and the post-loop processing would syntactically (e.g. with respect to variable scope) be outside the loop. While we are at CHILL: Another nifty syntactic sugar cube is the keyword EVER:
DO FOR EVER
...
ODThe semantics of EVER is quite obvious. I like this so much that whenever I need to program an inner loop in C, I set up a
#define ever (;;)
to be able to code it as "for ever {...}" in C. Sure, any well seasoned C programmer would prefer "while (1) {...}", but even though I have been writing more lines of C code than in any other language the last thirty years, I still read it as "while one what???"
-
In fact I seem to remember an "exit for" in QBASIC. Loop exits go way back in many BASIC compliers. But all you C# coders don't worry; you're still "the best". You'll become better coders as C# becomes more like BASIC. :wtf: LOL, sorry couldn't help myself. :-O
- great coders make code look easy - When humans are doing things computers could be doing instead, the computers get together late at night and laugh at us. - ¿Neal Ford?
-
In Python, loops can take an 'else' clause. It's run if you don't break out of the loop. For example:
for item in collection:
if some_test(item):
print('Found one!')
break
else:
print('No match found.')Yes, this is in the right direction. As your example illustrate, you do not have a symmetrical handling of the two ways out of the loop: The "breakout handling" is embedded in the loop code. with no syntactical indication that it is anything but ordinary actions within the loop. The 'else' provides half of what I want, and half is far better than nothing :)
-
After reading the python remark below I think I've got it (good thing you pointed that out! :thumbsup:) I'm not quite convinced of the benefits though. It may indeed - as the OP stated - safe you an extra
ifor flag variable. But the price you pay is readability: the conditional code can be in an entirely different place than the condition, with potentially a lot of code in between. Even worse, after reading over the OP again, it seems like there can be severalwhilestatements that can all trigger the sameexitwhile, meaning that there can be several conditons that are all in different places, separated from the conditional code and the other conditions as well! How on earth are you supposed to keep track of the flow of control in code like that? :confused: There may be cases where such a language construct may make sense, and even be better readable than the alternatives offered in C and other languages. But I sense a great potential of abuse, and I suspect it takes both experience and sense of responsibility to use it well. Should a programming language support such a feature? If you say "yes", will you also agree that cars should be allowed to use the sidewalks (provided they are wide enough)?. These are the same questions! So, the answer is also the same: we cannot assume that people will use that option responsibly, so we're better off without it!GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
You are right that in the Planc language you may have several 'while' conditions within a loop, and they all jump to the same exitwhile clause. If you need to distinguish between different reasons for leaving the loop prematurely, you must test variables in the exitwhile clause. It is important to note that block-wise (e.g. with respect to variable scopes), exitwhile is a part of the loop, so e.g. a for loop counter is available, as well as all local variables within the loop. We used this quite extensively, with one or more while exits, but very rarely there was a need to run alternate execution paths in the exitwhile clause; the cleanup actions, or reporting actions or whatever, was almost always the same for all early exits (but different for loop completion). I never saw any Planc programmer "abusing" this mechanism (even summer interns who were still students), and I cannot see how that abuse would be. If you need to handle the situation differently if you got to the end or if you did not get to the end, I see no cleaner way to do it in e.g. C constructs.
-
But does it provide two ways out? I.e. alternate code blocks executed one but not the other, depending on how you exited the loop?
It depended on the specific language’s implementation. The general rule was it exits from the innermost loop. I seem to remember VB (pre .NET) was able to break from nested loops…
do while true
for i = 1 to 10
if i > 5 then
exit do
end if
next
loopI also got something rattling around in my skull about exiting from named loops, but I don’t believe that was a BASIC language. Google/Bing isn’t being helpful at the moment. :(
- great coders make code look easy - When humans are doing things computers could be doing instead, the computers get together late at night and laugh at us. - ¿Neal Ford?
-
That is like break and continue in C, isn't it? Does it provide two alternatative ways out of a loop: One alternative is executed if the break was performed,the other if break was not performed? If it does, some more syntax must be defined.
I don't know C well enough to comment. And yes, if you need to know whether you exited the loop because of the break or the for/while/repeat condition, you have to code it separately. Usually there's some "natural" way to easily determine that, but obviously not always.
-
You are right that in the Planc language you may have several 'while' conditions within a loop, and they all jump to the same exitwhile clause. If you need to distinguish between different reasons for leaving the loop prematurely, you must test variables in the exitwhile clause. It is important to note that block-wise (e.g. with respect to variable scopes), exitwhile is a part of the loop, so e.g. a for loop counter is available, as well as all local variables within the loop. We used this quite extensively, with one or more while exits, but very rarely there was a need to run alternate execution paths in the exitwhile clause; the cleanup actions, or reporting actions or whatever, was almost always the same for all early exits (but different for loop completion). I never saw any Planc programmer "abusing" this mechanism (even summer interns who were still students), and I cannot see how that abuse would be. If you need to handle the situation differently if you got to the end or if you did not get to the end, I see no cleaner way to do it in e.g. C constructs.
At this point I think we're down to the question of personal preference. Every language has some features that people like and are missing in other languages. People preferring those other languages may not consider those features as desirable. Maybe because the typical tasks they work on have no use for it, or maybe because the programming guidelines they're used to would not leave room for them. Me, I don't see a need for
exitwhile/exitforin C/C++. I see sufficient alternatives, and while the risk for abuse is nowhere near the risk of statements likegotoor#definemacros, I'd still prefer to avoid it at the cost of slightly more verbose conditional code. Then again, I'm biased by the kind of code I usually work with: there's no day that passes without me having to skim over unfamiliar code, so everything that isn't obvious from a quick glance on the code, makes it harder for me to do my job. Therefore I prefer the conditions listed in one place, at the start (or in case of a do loop, at the end) of the loop. Having to scan the entire loop body to find out what conditions may have caused the loop to end just means extra work for me. Therefore I try to avoidbreakandcontinue(not to mentiongoto). And for the same reason I wouldn't welcomeexitwhile/exitfor.GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)