jwl@ernie.Berkeley.EDU (James Wilbur Lewis) (02/24/90)
In article <SUY1G_Fxds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >The right solution for Next C (whether it be P or D) is to defang break In this instance, perhaps C--? :-) ^^^^^^ >by using a different keyword for breaking from a switch or exiting from >a loop. I would suggest that 'break' be given a mandatory keyword argument: >either 'break switch', 'break for', and so on. Keyword? Why not a label? Then you could break all the way out of nested control structures without undue contortions. The default action could be to break out of the innermost appropriate structure, just the way it works now, so it would be an upward-compatible extension. The keyword contruction would be error-prone, for example if you change an inner loop from a for to a while, and forget to change the break keyword. foo: for( ... ) { bar: while( ... ) { switch(c) { case GOOD1: do_something(); break; case GOOD2: do_something_else(); break; case FUNNY: clean_up(); break bar; case DISASTER: die_horribly(); break foo; } } } -- Jim Lewis U.C. Berkeley
ckp@grebyn.com (Checkpoint Technologies) (02/27/90)
In article <34473@ucbvax.BERKELEY.EDU> jwl@ernie.Berkeley.EDU (James Wilbur Lewis) writes: >In article <SUY1G_Fxds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >>by using a different keyword for breaking from a switch or exiting from >>a loop. I would suggest that 'break' be given a mandatory keyword argument: >>either 'break switch', 'break for', and so on. > >Keyword? Why not a label? Then you could break all the way out of nested >control structures without undue contortions. The default action could be >to break out of the innermost appropriate structure, just the way it works now, >so it would be an upward-compatible extension. > >foo: > for( ... ) > { >bar: > while( ... ) > { > switch(c) > { > case GOOD1: do_something(); > break; > case GOOD2: do_something_else(); > break; > case FUNNY: clean_up(); > break bar; > case DISASTER: > die_horribly(); > break foo; > } > } > } I have my own pet idea for this, if you will all permit me :-) I like 'break label' myself, but the label should be positively identified as a label on a loop or switch construct. You should not be able to 'break' to any arbitrary label, 'goto' already does this. Instead place a label on the loop or switch: for label (i = 0...) { stuff switch swname (c) { cases break label; /* breaks from 'for' loop so labelled */ other cases break swname; /* break from 'switch' */ } } The label would have specific scope: only addressable by 'break' statements inside the loop/switch construct, not by goto's at all, not by break's outside the particular loop. Since the label leaves scope once the loop is closed, the same label could be used on subsequent loops. If the same label is used on a nested loop, it's either illegal or superceeds the prior label, and the outer lable reappears when the inner loop is closed. OK, that's my two cents. I'm not a language designer; I suspect that if this idea draws any attention at all it'll get picked apart...