Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!prls!pyramid!chronon!eric
From: eric@chronon.UUCP (Eric Black)
Newsgroups: net.lang.c
Subject: Re: What should be added to C
Message-ID: <279@chronon.chronon.UUCP>
Date: Mon, 2-Jun-86 19:06:56 EDT
Article-I.D.: chronon.279
Posted: Mon Jun  2 19:06:56 1986
Date-Received: Wed, 4-Jun-86 06:45:18 EDT
References: <1463@mmintl.UUCP> <2600059@ccvaxa>
Reply-To: eric@chronon.UUCP (Eric Black)
Organization: Chronon Computer Corp., Mtn. View, CA
Lines: 63
Summary: labels on "break"s

In article <2600059@ccvaxa> aglew@ccvaxa.UUCP writes:
>
>~> Multi-level breaks
>
>Why not use the Ada style of putting a label before the loop body - it's
>like giving a name to the loop:
>
>	complicated_loop: for(;;) {
>	    {{{{{
>		break complicated_loop;
>	    }}}}}
>	}
>
>No, it's not really much different from a goto.

Sure it's different!  The keyword "break" conveys much more information; it
implies an exit from some sort of loop or other shapely control flow
construct (what shape is "switch"?), whereas "goto" can mean just
about anything, including jumping INTO another control construct.
Having a name attached to it helps make it clear which control construct
is being exited.  There is no way that "break" can land you in the
middle of another block, or a "for" loop, or "do...while", but a "goto"
could.  This makes it easier to understand what is written.

The question is, just how much semantic content is to be attached to
that name?  I assume the compiler should complain if the name can't
be found as a valid label in a containing control construct; the name
is not just a comment for human consumption.
	firstloop: while(1) {
		/* something */
	}
	secondloop: while(1) {
		/* something else */
		break firstloop;
	}

But should the compiler FORCE the break to refer to the construct
which is named?
	outerloop: while(1) {
		/* something */
		innerloop: for(i=0; i<IMAX; i++) {
			/* something else */
			break outerloop;
		}
	}

This is something which is kind of awkward to express now without
either a goto (horrors!) or setting some flag which is examined inside
the outer loop but outside the inner one.

I like the idea of the compiler understanding the name attached to
a break statement, and warning if it thinks you're doing something
you don't expect ("do what I mean, not what I say!"); I think the
pre-processor should inspect and *enforce* similar labels on
#if/#ifdef blocks as well.  But again, I'm not at all sure that it
should do more than flag apparently out-of-place labels, or change
the semantics of the program if it were identical except without
the attached labels.  Scream about what it thinks I said, yes, but
don't presume to do what it thinks I meant!

-- 
Eric Black   "Garbage In, Gospel Out"
UUCP:        {sun,pyramid,hplabs,amdcad}!chronon!eric