[net.lang.c] Breaking out of labeled statements

ggs@ulysses.UUCP (08/23/83)

Sounds like a fine idea, it would have eliminated the last
few 'goto's that I used.  And how about

continue label

for nested loops.  I would probably use that one just for clarity
in a single loop.  Sometimes the object of the 'continue' gets lost
in the nesting.  (I know, call out the purity squad and take him away).
-- 

Griff Smith	Bell Labs, Murray Hill
Phone:		(201) 582-7736
Internet:	ggs@ulysses.uucp
UUCP:		ulysses!ggs

rbk@sequel.UUCP (08/24/83)

When I was at the U. of Wisconsin and took the compiler course, we created
a compiler for a language called "NOGO-III" (ie, 3rd version of a goto-less
language).  It supported the labelled "break" and "continue", was quite
reasonable, and eliminated almost all need for gotos (in fact, since there
was no goto, you were stuck if you thought you needed one).  I have always
been disappointed that C didn't support such a feature.  Maybe it should be
added to various "standards" or future versions of the language...
-- 
	Bob Beck
	Sequel Computer Systems
	...ogcvax!sequel!rbk
	(503)627-9809

riks@shark.UUCP (Rik Smoody) (08/25/83)

I just don't see that a lot of gibberish with setbreak(someflag),
testbreak(someflag), multibreak(someflag), and several
occurrences of breakout(soemflag) is any more clear for
human readers, any more efficient for computers, or any easier for
a compiler to handle than a simple GOTO.

The suggestion of a labelled break, on the other hand, seems to simplify
and eliminate both the harm of a goto and the need to use them.

ptw@vaxine.UUCP (P. T. Withington) (08/29/83)

On the other hand, ECL was rather mind-blowing in power.  I always liked to
think of it as "the civilized man's Lisp".  Any other fans out there?  What
ever became of ECL?  Where have all the flowers gone?  Etc., etc.

jsq@ut-sally.UUCP (08/30/83)

>		(CAUTION)
>
>	Labeled breaks sound reasonable, but leave it at that please.
>I had the excruciatingly unpleasant experience of working in a language
>called ECL (or EL1 -- your choice) at Harvard. Among other unpleasantries
>the language supported labeled blocks that you could break out from anywhere
>within the block (even from subroutines called within the block) with
>some command like "=> <label>".  The language was written in such a way
>that you were occasionally forced to use this construction -- and it
>was a roaring pain to debug.
>
>Craig Partridge
>cfib!craig

The language was called EL/1, the support package was called ECL.
It's all in what you're used to:  I found the language quite easy to
use and debug.  Certainly easier than tracing down longjmps and gotos.
-- 
John Quarterman, CS Dept., University of Texas, Austin, Texas
{ihnp4,ut-ngp}!ut-sally!jsq, jsq@utexas-780.ARPA (soon to be jsq@ut-sally.ARPA)

craig@cfib.UUCP (08/30/83)

#R:ulysses:-57000:cfib:5900003:000:568
cfib!craig    Aug 26 15:05:00 1983


		(CAUTION)

	Labeled breaks sound reasonable, but leave it at that please.
I had the excruciatingly unpleasant experience of working in a language
called ECL (or EL1 -- your choice) at Harvard. Among other unpleasantries
the language supported labeled blocks that you could break out from anywhere
within the block (even from subroutines called within the block) with
some command like "=> <label>".  The language was written in such a way
that you were occasionally forced to use this construction -- and it
was a roaring pain to debug.

Craig Partridge
cfib!craig

preece@uicsl.UUCP (08/31/83)

#R:ulysses:-57000:uicsl:6400006:000:701
uicsl!preece    Aug 30 11:13:00 1983

The SAIL language allows the BEGIN and END 'statements' to be
followed by string constants. Those constants are then matched
by the compiler, making missed delimiters very easy to identify
and fix, and can be used in break and continue statements.

Another thing that would be very useful in case statements
would be a 'recase'  verb, which would restart the enclosing
switch (i guess in C it would be 'reswitch'). It is often useful
to be able to recognize some cases as only minor variants of
others, and process them by using a prologue for one variant
followed by the existing case treatment shared between them.
A reswitch verb would make this trivial.

scott preece
pur-ee!uiucdcs!uicsl!preece

alan@allegra.UUCP (08/31/83)

	Another thing that would be very useful in case statements
	would be a 'recase'  verb, which would restart the enclosing
	switch (i guess in C it would be 'reswitch'). It is often useful
	to be able to recognize some cases as only minor variants of
	others, and process them by using a prologue for one variant
	followed by the existing case treatment shared between them.
	A reswitch verb would make this trivial.


In certain cases, C allows you to do exactly what you're asking for.

	switch (a) {

	  case ONE_THING:
		/* code for ONE_THING */
		break;

	  case A_VARIATION_ON_A_SECOND_THING:
		/* prologue, then fall through... */

	  case A_SECOND_THING:
		/* common code for A_SECOND_THING and variation */
		break;

	}

Of course, there can't be two variations, each with its own prologue,
of one case, so this is of limited use.


	Alan Driscoll
	Bell Labs, Murray Hill

guy@rlgvax.UUCP (Guy Harris) (09/01/83)

"goto"s can be used for treating several cases as subcases of one common
case (i.e., do the case-specific thing and then the common actions), generally
without too tangled code.  Furthermore, if it *does* tangle things, or you don't
want to use "goto"s, many versions of the C "final" optimizer will do the right
thing if you write something like

	case (foo) {

	case 1:
		/* 1-specific things */
		/* common code */
		break;

	case 2:
		/* 2-specific things */
		/* common code */
		break;

		.
		.
		.

and join the common code and stick a jump/branch instruction into the cases.
(Versions known to: PDP-11, VAX-11, Zilog "Zeus", CCI - and probably most
other - 68000).

	Guy Harris
	{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy

craig@cfib.UUCP (09/02/83)

#R:ulysses:-57000:cfib:5900004:000:400
cfib!craig    Sep  1 11:31:00 1983


	In response to John Quarterman... Indeed, ECL is the support
package and EL/1 is the language -- people at Harvard rarely bother to 
distinguish anymore.  I'm more surprised to hear that you actually liked
programming in the language.  It puts you in a rare class -- most people
I know despise it, and indeed, try to avoid the two courses at Harvard 
that still use it.

Craig Partridge
cfib!craig