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") endfor
No 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 =
-
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") endfor
No 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 =
Shirley, using
goto
is simpler.I wanna be a eunuchs developer! Pass me a bread knife!
-
Shirley, using
goto
is simpler.I wanna be a eunuchs developer! Pass me a bread knife!
burn the heretic, burn him I say
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
burn the heretic, burn him I say
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
Lookit, you might not actually type the word
goto
, but when you compile your code, every transition from one statement to another is translated into agoto
.I wanna be a eunuchs developer! Pass me a bread knife!
-
Lookit, you might not actually type the word
goto
, but when you compile your code, every transition from one statement to another is translated into agoto
.I wanna be a eunuchs developer! Pass me a bread knife!
burn him (since when has facts got in the way of religion) burn the heretic
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
burn him (since when has facts got in the way of religion) burn the heretic
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
Yup, religions want to be the middle man (between man and god, man and his money, etc.), so they love middle-man things, like all these statements that do nothing more than abstract the
goto
.I wanna be a eunuchs developer! Pass me a bread knife!
-
Lookit, you might not actually type the word
goto
, but when you compile your code, every transition from one statement to another is translated into agoto
.I wanna be a eunuchs developer! Pass me a bread knife!
Not true: in some machines it's called a JUMP instruction instead!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
-
Not true: in some machines it's called a JUMP instruction instead!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
Ah, but if you look at the compiled machine code, it's exactly the same, so
JUMP
is just another abstraction ofgoto
.I wanna be a eunuchs developer! Pass me a bread knife!
-
Yup, religions want to be the middle man (between man and god, man and his money, etc.), so they love middle-man things, like all these statements that do nothing more than abstract the
goto
.I wanna be a eunuchs developer! Pass me a bread knife!
-
If we are not going to burn him then I going to sulk
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
Now I'm going to have to visit that place.
Never underestimate the power of human stupidity RAH
-
burn him (since when has facts got in the way of religion) burn the heretic
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
I believe you'll find that all those accounts written hundreds of years after the alleged events were entirely factual... :~
-
If we are not going to burn him then I going to sulk
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
As long as you do it quietly.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Certainly not the conference. Not one of the presentations is about the
goto
. They should be done for false advertising.I wanna be a eunuchs developer! Pass me a bread knife!
-
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") endfor
No 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 =
What about this?
foreach (x in someContainer)
{
ret = someFunction(x);
}
int someFunction(whatever x)
{
// do stuff
if (someCondition) return 1;// do more stuff if (someOtherCondition) return 2; // ... return 3;
}
Is this close to what you meant, or did I miss the point?
-
As long as you do it quietly.
I wanna be a eunuchs developer! Pass me a bread knife!
humph
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
What about this?
foreach (x in someContainer)
{
ret = someFunction(x);
}
int someFunction(whatever x)
{
// do stuff
if (someCondition) return 1;// do more stuff 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 exitforlabelexitwhilelabel:
... object found
goto endforlabelexitforlabel:
... object not found
goto endforlabelendforlabel:
endforThis 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.)
-
Lookit, you might not actually type the word
goto
, but when you compile your code, every transition from one statement to another is translated into agoto
.I wanna be a eunuchs developer! Pass me a bread knife!
-
Shirley, using
goto
is simpler.I wanna be a eunuchs developer! Pass me a bread knife!
-
What about this?
foreach (x in someContainer)
{
ret = someFunction(x);
}
int someFunction(whatever x)
{
// do stuff
if (someCondition) return 1;// do more stuff if (someOtherCondition) return 2; // ... return 3;
}
Is this close to what you meant, or did I miss the point?
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