Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site redwood.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!zehntel!dual!amdcad!fortune!rhino!redwood!rpw3
From: rpw3@redwood.UUCP (Rob Warnock)
Newsgroups: net.lang.c
Subject: Re:  hashing external names & other goodies.
Message-ID: <109@redwood.UUCP>
Date: Wed, 9-Jan-85 17:06:43 EST
Article-I.D.: redwood.109
Posted: Wed Jan  9 17:06:43 1985
Date-Received: Sun, 20-Jan-85 07:53:07 EST
References: <7096@brl-tgr.ARPA>
Organization: [Consultant], Foster City, CA
Lines: 63

+---------------
| Yuck!  "break <n>;" is an accident looking for a place to happen!
| If one has to have this facility, "break <label>;" is far superior.
+---------------

I second the motion. The BLISS-10 language (which has no explicit "goto")
originally had "EXITWHILE" and "EXITCASE" and "EXITBLOCK" and... so they
added a simple "EXIT n".  Well, after a while they got tired of the hassle
and replaced all that with labelled blocks so you can "LEAVE label".
In pseudo-C:

	foo:{	...
		... break foo;
		...
	    }

If one were to add this to "C" I would suggest somehow managing to force
a label onto the END of the block which matches the one at the beginning,
so that it is easy to scan forward and see where the block ends.

But note that "C" already HAS this construct, if one doesn't mind some
disciplined use of "goto".  (I have seen this style already in some code.)
Simply put the label just INSIDE the END of the block:

	#define leave goto	/* preferably deep in a header file */

	    ...
	    { /*BLOCK foo*/
			...
			... leave foo;
			...
	    foo:}
	    ...

The point of using "leave" rather than "goto" is to emphasize that one
is using a hierarchical control flow, and not jumping all over the place.
Again, the disclipline of labeling the block entry is very important, as
otherwise the reader hits the "leave foo" without knowing he/she is IN "foo"!

(Any flamers about "goto" should recognize first that "return" is in fact
just such a structured forward "goto". Dijkstra's paper was about the
UNRESTRICTED use of "goto", not the existence of it at all.)

Whether or not you have it in the compiler is not particularly important as
far as code generation -- a decent data-flow/control-flow analyzer can easily
deal with such forward-and-out "goto"s --  nor to ENFORCE the discipline
(since as long as "C" has the unrestricted "goto" one must hope the programmer
does not write spagetti code), but simply so that the compiler could check
that the brackets and labels match (no use of "leave label" if we're not
in a block named "label").

So finally, perhaps we should simply extend "lint" to warn of any "goto"
whose target is not just inside the end of an enclosing block, and leave
the poor compiler alone! (One could even get "lint" to check that the
block started with a "/*BLOCK foo*/" comment!)


Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	510 Trinidad Lane, Foster City, CA  94404