|
Why, thank you, Shirley.
They say that elegance is simplicity, so I must be pretty elegant.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Goto the cockpit and see what the hold up is.
And don't call me Shirley.
|
|
|
|
|
What about this?
foreach (x in someContainer)
{
ret = someFunction(x);
}
int someFunction(whatever x)
{
if (someCondition) return 1;
if (someOtherCondition) return 2;
return 3;
}
Is this close to what you meant, or did I miss the point?
|
|
|
|
|
Still you must analyze those "ret" values, and values 1, 2, 3 do not syntactically convey the information that you reached the end of the collection (or skipped out of the loop). You need this extra "ret" value, which must be declared for this one-time use. While your proposal might be a starting point for explicitly coding what the compiler might generate, it certainly does not have the readability and syntactical clearness that the exitfor/exitwhile syntax has.
Also, I doubt that the compiler would code it as a function. It would generate one jump label for the exitwhile clause, another for the exitfor (both defaulting to the first statement following the loop). The top line iteration test would jump to the exitfor label when the looping condition fails, the while statements would jump to the exitwhile label when it fails.
If the language would provide block local program labels, visible only within the loop, I could code my example as
for listpointer = listhead:nextfield do
...
if listpointer.keyvalue = desired_key goto exitwhilelabel
...
if listpointer.nextfield = null goto exitforlabel
exitwhilelabel:
... object found
goto endforlabel
exitforlabel:
... object not found
goto endforlabel
endforlabel:
endfor
This is what a reaonable compiler would generate - but I think it ugly when written out in longhand code. Besides, jump labels do not have block local scope in any language I know of, so you would have to invent new labels for every loop using this mechanism ("if listpointer.keyvalue = desired_key goto exitwhilelabel117" - even more ugly!)
I tried to make C macros that would generate unique labels, but the problem was to make the asocciation between the while part (or if test in the code above) and the appropriate exitwhile. A compiler could easily do this.
(Tne "goto endforlabel" in the exitfor clause is redundant and would be optimized away, but it allows the exitfor and exitwhile clauses to be switched around.)
|
|
|
|
|
I'd suggest an enum over magic numbers.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
 I like that ... for that matter, why loop at all? Just use goto and loose the while/for - just wear some flame retardant apparel.
Actually, hang on, why even use goto? Why not copy-paste the code the required number of times instead of looping at all! Yeah! That's what Id do! 
|
|
|
|
|
I haven't read all the responses that may or may not give a hint in that direction, but what exactly is it that these commands do that a break statement in C doesn't?
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)
|
|
|
|
|
Here is a real world example for you
for (property = 0, len = obj.length; property < len; property++) {
if (callback.call(obj[property], property, obj[property]) === false) {
break;
}
}
Once the following is true (callback.call(obj[property], property, obj[property]) === false), there is no point in continuing the loop, as a result the break will exit the loop.
If the method has the answer it is looking for, you can also do
for (property = 0, len = obj.length; property < len; property++) {
if (callback.call(obj[property], property, obj[property]) === false) {
return 1;
}
}
so that not only will the loop end, but if there is nothing more in the method which will add value to the answer, the data is returned without needing to continue (bad choice of words, since continue has it's own special meaning) the loop and without needing to look at any more code.
|
|
|
|
|
That wasn't my question at all. I know what break does. And exactly because I understand what it does, I do not understand the original question!
I don't know Planc, but from the original posting my understanding was that the commands pointed out there - exitfor, exitwhile - simply exit from the loop. Just like break does. I don't see the difference, and therefore I don't see the point of the question.
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)
|
|
|
|
|
After a loop, how do you know if you finished it or breaked out of it?
This post is not about just leaving a loop, but about knowing how you left it and act according it.
We probably all know how to do that in c, but this is about a language that adds syntax elements for that.
|
|
|
|
|
Looks like a nonsense reason, to me. You can just put a message before the break statement.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: You can just put a message before the break statement.
Goto! Before the goto statement!
Damn!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
How do you know the difference in Planc if you used exit***?
As I said, I don't understand what, exactly, these statements do, and the OP doesn't inidicate they do anything beyond breaking out of the loop. That's what break does, too. Hence my question.
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)
|
|
|
|
|
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!  )
I'm not quite convinced of the benefits though. It may indeed - as the OP stated - safe you an extra if or 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 several while statements that can all trigger the same exitwhile, 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? 
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.
|
|
|
|
|
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/exitfor in C/C++. I see sufficient alternatives, and while the risk for abuse is nowhere near the risk of statements like goto or #define macros, 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 avoid break and continue (not to mention goto). And for the same reason I wouldn't welcome exitwhile/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)
|
|
|
|
|
"Are there other languages out there with something similar?"
Python has this "syntactic sugar" for alternate loop exit:
for item in iterable:
if condition(item):
break
process(item)
else:
print("No item in iterable meets the condition")
The else signifies that the for loop has finished without "break"-ing.
|
|
|
|
|
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
|
|
|
|
|
Visual Basic.NET supports similar constructs, such as:
Exit For
Exit While
Exit Do
and continuations like:
Continue For
Continue While
Continue Do
|
|
|
|
|
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. 
LOL, sorry couldn't help myself. 
- 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?
|
|
|
|
|
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
loop
I 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?
|
|
|
|
|
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!!! 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
