using break <label> instead of goto <label>

[Guy Harris]

> Not quite.  You see, if you follow out this philosophy, we can do away with
> for(;;) and while() and the else in if()-else ... and compound statements
> too.

Yes, but

	while (<condition>) {
		...
	}

is easier to read and write than

loop:
	if (!<condition>)
		goto endofloop;
	...
	goto loop;

while one "ed" command, or one #define, can turn

	while (<condition>) {
		...
		breakloop label;
		...
	}

label:

into its "goto" equivalent.  (Putting the label at the beginning of the
loop would make that harder, but it would also make it harder for the reader
to find the point that the "breakloop" goes to.

> The labelled break allow you to get out of (i.e. go to just below) a loop
> without making it possible to get there from anywhere else.

Except for one problem: nobody's proposed deleting "goto" from the C language
(and anybody who proposes it should personally have to rewrite every program
that uses it safely).  As such, C *will* let you get anywhere from anywhere
else (within a function body, at least) even with the addition of the "break
<label>" construct.

If we're designing a *new* language, we might consider fancier "break"
statements and no "goto" (although even "break" and "continue" can impair
the readability of a program).  Since C already has a "goto", though, and
it's impractical to eliminate it, I don't think "break <label>":

	1) makes the language easier to write in
	2) makes it easier to read programs
	3) makes it easier to verify programs
	4) makes it easier to optimize programs

I presume that any flowgraph that for a program written with "safe" "goto"s
can be rewritten either with "break <label>" and "continue <label>", or by
node splitting (i.e., where "goto" is used as a way of folding code).  This
is probably close to a formal statement of my notion of "safe" "goto"s, and
probably close to most other people's notion as well.  If so, you can
formally eliminate "goto"s from programs, so the only question that comes up
is whether the informal aspects of readability and writability are affected
by the addition of "break <label>".  I don't think it's affected enough
to make it worth the trouble of adding "break <label>" to the language.  As
I've said, even unlabelled "break" and "continue" statements can impair
readability; it's harder to find the end of a loop when examining its innards
in detail than when looking at the loop as a whole, so that it is less obvious
what the flow of control is when looking at the "break" in

	while (<condition>) {
		...
		if (<condition 2>)
			break;
		...
	}

then when looking at the "while" loop as a whole.  (I.e., it's more obvious
that control flows from the code before the closing "}" to the condition
test on the "while" line than it is that control flows from the "break"
statement to the code after the closing "}".)  I would still use a "break"
in this case, out of habit and out of a partially-superstitious desire to
avoid a "goto", even though putting in a label might make it easier to
see where the "goto" goes to; also because it means I don't have to invent
a name for the label.  Putting in a "break <label>", however, means I have
to invent a label.  And if the label goes at the beginning of the loop,
rather than the end, you have to search for the label and then search for
the end of the loop to figure out where it goes.  This is becoming a
problem in the psychology of programming; does anybody have any hard evidence
for or against the proposition that labelled breaks - of either kind - make
it easier to program?  If not, we're all trading anecdotal evidence, and
the horse's corpse is beginning to look a bit messy...

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy