Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pacbell!att-ih!att-cb!clyde!watmath!watmsg!pabuhr
From: pabuhr@watmsg.waterloo.edu (Peter A. Buhr)
Newsgroups: comp.lang.misc
Subject: Re: Loops
Message-ID: <17911@watmath.waterloo.edu>
Date: 30 Mar 88 13:04:30 GMT
References: <2827@enea.se> <1557@pasteur.Berkeley.Edu> <2773@mmintl.UUCP> <294@tmsoft.UUCP> <2488@bsu-cs.UUCP>
Sender: daemon@watmath.waterloo.edu
Reply-To: pabuhr@watmsg.waterloo.edu (Peter A. Buhr)
Organization: U. of Waterloo, Ontario
Lines: 46

In article <2488@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>In article <294@tmsoft.UUCP> mason@tmsoft.UUCP (Dave Mason) writes:
>>...
>Unfortunately, somebody modifying code with such a construct will
>seldom be sure that he has tracked down all the exit points.  The same
>problem exists with goto, exit, break, etc.
>
>A possible solution:
>
>     do (2 exits)
>	...
>	while expr
>	...
>	while expr
>	...
>     done
>
>The assertion "(2 exits)" tells the compiler to flag a syntax error if
>the number of loop exits is not exactly 2.  The default, in the absence
>of this assertion, could be exactly one exit.  Also "(no exits)".

A much easier solution is to outdent the exit conditions, as in:

      do
         ...
      while expr
         ...
      while expr
         ...
      done

It is then possible to scan down the margin of the loop and see very
quickly all the exit points. This is the same mechanism that is used
to locate the else clasue of an if statement, as in:

     if ... then                  if ... then
        ...                          ...
        else            vs.       else
        ....                         ...
     end if                       end if

For a more detailed discussion on this stuff see:

Buhr, P. A.
A Case for Teaching Multi-exit Loops to Beginning Programmers.
SIGPLAN Notices,
vol. 20, no. 11, November 1985, pp. 14-22