ddb@mrvax.DEC (DAVID DYER-BENNET MRO1-2/L14 DTN 231-4076) (10/10/84)
This is an extremely valuable feature; its use makes for much more readable, structured, code than anything except the "goto" approach, and it is clearly superior to that as well (just not as much). The proposed method, assigning a "label" to a block of code and then saying "break label;" to break out of that block, is exactly the correct way of doing it, in my opinion. Bliss has such a feature, which I have used, and find quite useful. There is another way of doing it, brought to mind by calling this a "break n" capability. This way of doing it is, in my opinion, WRONG WRONG WRONG! The older Bliss-10 language had an "exitloop n" construct where n was the number of enclosing loops you were going to exit from. First, this was hard to read, because you had to carefully find all the loops, and count them. Far worse, however, was that the addition of another loop surrounding the code in question could cause it to become invalid!!! Obviously, this gets worse very rapidly (exponentially?) as the value of n increases. So, my vote: "Break label" Yes Yes Yes "Break n" No No No -- David Dyer-Bennet -- ...decwrl!dec-rhea!dec-mrvax!ddb
ron@brl-tgr.ARPA (Ron Natalie <ron>) (10/11/84)
FOO! Who defined structured programming as: Structured programming is any construct that does not use GOTO statements. Not Dijkstra, not Knuth. Disguising goto's as multi-functional break statements is not helping the problem. C doesn't need these. If you want to be non-structured, use GOTO. At least it's clear what you are doing. -Ron
chuqui@nsc.UUCP (Zonker T. Chuqui) (10/12/84)
> The proposed method, assigning a "label" to a block of code and then saying > "break label;" to break out of that block, is exactly the correct way of > doing it, in my opinion. Bliss has such a feature, which I have used, > and find quite useful. Can someone PLEASE tell me what the difference between the current 'goto label' in C and the proposed 'break label' is? Sounds simply like a goto under another nane to me.... -- From the Department of Bistromatics: Chuq Von Rospach {cbosgd,decwrl,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA How about 'reason for living?'
dick@tjalk.UUCP (Dick Grune) (10/15/84)
> Can someone PLEASE tell me what the difference between the current 'goto > label' in C and the proposed 'break label' is? Sounds simply like a goto > under another nane to me.... > -- > From the Department of Bistromatics: Chuq Von Rospach > {cbosgd,decwrl,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA The difference between 'goto label' and 'break label' is that 'goto label' goes to the BEGINNING of the statement labelled 'label' and 'break label' goes to the END of the statement labelled 'label'. This also nicely explains the semantics of foo: x++; break foo; :-) :-> :-} Dick Grune Vrije Universiteit Amsterdam "and my name isn't Richard"
quiroz@rochester.UUCP (Cesar Quiroz) (10/18/84)
Some more comments. > From: Barry Gold <lcc.barry@UCLA-LOCUS.ARPA> > > . . . > > If "break label;" is to be allowed, the language definition should at least > allow (if not require) a matching label at the end of the loop. > . . . This is a sound DESIGN idea. It not only makes the finding (while reading) of the end of the loop easier, but provides a check the compiler can make for essentially every loop (namely, Is this the end of the loop the programmer was thinking about?) The only difficulty I can see is that the language would change too much for the standard to be useful. Admittedly, the original proposal is half-hearted and the addition of the final label would improve it. However, if the original proposal finds its way to the standard (fat chance! not even the originator is defending it any further), NO working C program will be broken. It's a matter of compromise: the proposed additions should disturb the language as little as possible. Some additional functionality should be gained at little cost. For the final label to be really useful, it need be mandatory. But that seems a bit too much: current programs will be broken mercilessly. Maybe a little bit of programmer's maturity will help, in the form of comments. But that is beyond this discussion. (Because we ALL comment at the end of a loop, don't we?) However, if you can come with a syntax that doesn't break existing programs and provides the needed cleanliness, be it welcome. (I have my doubts, though. I think the best solution is terminating keywords for all compound statements and that crashes heads on with the nice/silly braces). Cesar