anton@ucbvax.ARPA (Jeff Anton) (01/13/85)
I don't know what to think about all this discussion about
how redefine the break statement to take labels. While it's
probably good to get away from the goto statement, I can't help
but think that this is not the way to go. C has, for the most part,
reached its current level of popularity from UNIX. It was designed
to replace assembly language for the higher level functions of
operating systems. To do this it needed the ability to be coerced
into doing things not directly expressable in ordinary varables.
C did not always have casts. I wonder how many people knew this.
Casts were a much better notational system than the reliance on
loosly checked structure use. Anyway, I should get to my point.
If we adopt a new break statement, are we going to adopt the
analogous change to the continue statement?
I can't keep track of all the variations of the break syntax.
None of them have the immeadate clarity I'm use to in codeing in C.
Could someone point me at a language that has labeled loops
without gotos? I do prefer structured languages. But I don't
agree with the compleate banishment of the unrestricted branch.
In any language, I consider the goto statement perfectly valid
for use to branch out of a nested construct to following code.
(Stay within the same procedure of course.)
Goto's make excellent statements about how carefully code should
be read. If I see a label, I scan for the goto, figure out why
it's needed, and understand what's going on. Goto's are
statements that must be commented. Any statement that does something
complex should be commented, and I consider any situation where
one needs to leave two of more nesting levels suffiantly complex.
This all comes down to what the programmer thinks when he sees
a break or a label. What do the labeled loop people think of
breaking switches?
procsearch: for (proc = proctab; proc < proctab+MAXPROC; proc++) {
do_stuff;
while (busy)
if (cond)
break procsearch;
}
Is this analogous or allowed?
flagsw: switch (*argv[1]) {
case 's':
switch (*argv[2]) {
case 'b':
break flagsw;
...
}
...
}
/* execution comes here after the break */
I strongly object to this type of labeled switch.
I don't think that the language change should be made unless it is
uniform, and I don't think that a compromise can be made between
loop labeling and switch labeling. Carefull use of gotos is
clearer and more consistant I think.
--
_________________________
C knows no bounds.
Jeff Anton
U.C.Berkeley
ucbvax!anton
anton@berkeley.ARPArpw3@redwood.UUCP (Rob Warnock) (01/13/85)
+--------------- | I can't keep track of all the variations of the break syntax. | None of them have the immeadate clarity I'm use to in codeing in C. | Could someone point me at a language that has labeled loops | without gotos? I do prefer structured languages. But I don't | agree with the compleate banishment of the unrestricted branch. +--------------- The BLISS language, which is about as old as "C", has no "goto" at all. ("Never did, never will...") It DOES have the "leave <label>" construct, where the label can be put on ANY block, not just loops. (Since it is an expression language, you can also "leave <label> with <value>", and of course, "return <value>" is just shorthand for "leave <current-procedure> with <value>".) +--------------- | In any language, I consider the goto statement perfectly valid | for use to branch out of a nested construct to following code. | (Stay within the same procedure of course.) +--------------- Yes, but C's "goto" allows branching INTO nested constructs, too. +--------------- | ... What do the labeled loop people think of | breaking switches?... | Is this analogous or allowed? | flagsw: switch (*argv[1]) { | case 's': | switch (*argv[2]) { | case 'b': | break flagsw; | ... | } | ... | } | /* execution comes here after the break */ +--------------- This is PRECISELY what the BLISS "leave" does. +--------------- | I strongly object to this type of labeled switch. | I don't think that the language change should be made unless it is | uniform, and I don't think that a compromise can be made between | loop labeling and switch labeling. Carefull use of gotos is | clearer and more consistant I think. | Jeff Anton | U.C.Berkeley | ucbvax!anton | anton@berkeley.ARPA +--------------- The key is going far enough in making the language construct uniform. Remember, everything a "leave" can do, a "goto" can already do in C. (Just put the label AFTER the second right bracket.) If you object to using a "leave" in the above case you must ALSO object to using a "goto", to be honest. It is easier to be "careful" if the language contains constructs which restrict what you can do to what you need in a particular situation. (That's why we have "for" and "while" and "switch" at all!) When you see a "goto" in the text, you normally have NO IDEA where it's going without reading the rest of the program. When you see a labelled block, you immediately know that it's going to be left (otherwise there would be no label), so you can keep that in mind as you read. When you see the "leave", you know what scope is being left (you don't have to count right-brackets). The incidence of the "goto" in C code is so rare anyway, I dare say we could abolish it altogether (replacing it with BLISS's "leave") and not miss the loss. (I certainly never missed it in BLISS.) Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
geoffrey dov cooper <MLY.G.SHADES%MIT-OZ@MIT-MC.ARPA> (01/31/85)
if we really are (which i doubt) going to go with
break/continue <identifier> then perhaps we should provide some
isolation so that it is distinguishable from a goto label. maybe
<identifier>:: <control structure>
break <identifier>;
the double colon would show that this is a control structure label and
not a goto label thus eliminating some of my objections to the
structure.
shades@mit-oz.arpa
-------