From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Subject: Re: A challenge to the anti-goto
Organization: Purdue University Statistics Department
Date: Fri, 6 Nov 1992 10:25:24 GMT

In article <1992Nov04.093942.13535@cadlab.sublink.org> martelli@cadlab.sublink.org (Alex Martelli) writes:
>jhauser@pine.CS.Berkeley.EDU (John Hauser) writes:

			...............................

>:	When coded in C, Herman's algorithm cannot be efficiently
>:	implemented without at least one label (`start'), and
>:	corresponding `goto's.
>:(I look forward to seeing this claim refuted!)

>It seems to me that exactly ONE of the 5 "goto start" constructs may
>give problems:  the last one, since it's embedded within another loop.
>All others could be replaced easily by changing the "start:"  label into
>a "for(;;) {", add a corresponding "break;}" at the end of the loop, and
>changing all "goto start;" into "continue;"; so at least 80% of the
>"corresponding `goto's" are removed (whether it is at all "beneficial"
>to do so is another question, of course!).

There are two questions here.  One of them is producing workable code;
and at least some of the responders have succeeded in showing that in
some languages this can be done.  I never doubted this.  Also, remember
that this was not my first posting of the code; I posted the version in
which all control statements were by gotos, which BTW for someone who
uses gotos is quite easy, more to make sure I had no C errors than as
optimal code.  Switch statements, normal writing of loops, etc., are
quite fine with me.

But the other part of my challenge is producing efficient code.  To
do this, it is necessary for the case 1 code to fall into start, and
for the rejection cases, to have the case statement cause a transfer
to start.  Whether an implementation will cause

	case 3: break;

to be a transfer to start, rather than a transfer to the case 3: code
and then a transfer to start is problematical.

In addition, I have seen no code (other than possibly the Lisp code
which it will take me some work to read) which successfully avoids
the gotos on exit from the loop to the label^n section of the code
without using a construct which is essentially equivalent to it or
by paying a price.

>Break-from-loop and iterate-loop from within another nested loop (and,
>due to the 'overloaded' nature of the break keyword, break-from-loop
>from within a switch!) are indeed a functional limitation of C, i.e.,
>no can do without goto or some flag-variable.

>:	If we've known about this problem for twenty years, why don't we
>:	have more powerful `break' instructions in our existing languages??

>:Beats me.

>But we DO.  The hugely popular perl language allows one to label a loop
>and use the label as an operand of the "next" (same as C "continue")
>and "last" (same as C "break") keywords.  I seem to recall that PL/I
>used a similar idea, and perhaps REXX, another very popular language.
>Just to clarify, the above could be something like:

Is Perl suitable for code as I have written, or REXX.  PL/I suffered
from clumsy syntax, as does ADA and assembler, and from what I have
seen of it, Lisp.  For the person writing code, syntax is extremely
important, and clumsy syntax does not help the reader.  It MAY help
the compiler, however; assemblers would have to work harder if the
instruction mnemonic did not come first.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)