From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,9a0ff0bffdf63657
X-Google-Attributes: gidfac41,public
X-Google-Thread: 103376,4b06f8f15f01a568
X-Google-Attributes: gid103376,public
X-Google-Thread: 1108a1,9a0ff0bffdf63657
X-Google-Attributes: gid1108a1,public
X-Google-Thread: f43e6,9a0ff0bffdf63657
X-Google-Attributes: gidf43e6,public
From: doylep@ecf.toronto.edu (Patrick Doyle)
Subject: Re: Software landmines (loops)
Date: 1998/10/11
Message-ID: <F0n3Ko.76A@ecf.toronto.edu>#1/1
X-Deja-AN: 399887074
X-Nntp-Posting-Host: skule.ecf
Sender: news@ecf.toronto.edu (News Administrator)
References: <dewar.903281994@merv> <35ece7ee.1489912@news.erols.com>
 <m31zpq4pim.fsf@mheaney.ni.ne <m3af36wtwh.fsf@mheaney.ni.net>
Organization: University of Toronto, Engineering Computing Facility
Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada
Date: 1998-10-11T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <m3af36wtwh.fsf@mheaney.ni.net>,
Matthew Heaney  <matthew_heaney@acm.org> wrote:
>
>There are two ways to turn this into a loop.  The most natural way
>(according to me, and Soloway et al) is like this:
>
>loop
>   read N
>   exit when N = 0
>   process N
>end loop
>
>This describes the enumerated list of actions above.  The "classic" way
>is like this:
>
>read N
>
>while N /= 0 loop
>   process N
>   read N
>end loop
>
> [...]
>
>I argue that the middle-exit construction shown above satisfies
>Dijkstra's "restricted topology" in the sense that a reader of the
>(static) program text can easily understand what happens at run-time.

You make some good points.

I'd just like to add that another desirable property of a loop is
that all exit conditions are concentrated in one place.  This,
in combination with my own preference for the first form (above)
rather than the second (which repeats the "read N" part), led
me, a while back, to propose a loop syntax like this:

until exit{end_of_file} loop
  read N
  if N = 0 then exit(end_of_file);
  process N
end loop

This has the advantages of your first method with the added benefit
that the exit conditions are concentrated in one place, for easy
comprehension.  

Clearly, this could already be done without special syntax simply by
declaring a boolean flag and then, perhaps, relying on the compiler
to optimize it away.  However, it would be nice to be able to express
to the compiler that you don't want a flag; you are simply trying
to describe the flow of control through the loop.

Another point is that it is important for the program to be able to 
discern the reason for loop termination.  You should be able to say "if
end_of_file" after executing the loop.  However, again, this should
not be translated into a boolean flag test.  Again it's just
describing the flow of control.

What I'm trying to say is that we should be guaranteed that
the compiler will turn this:

	loop
	  A;
	  if B then exit(condition1);
	  C;
	until 
	  exit{condition1} or condition2 
	end loop

	if condition1 then
	  D;
	end if
	E;


...into something like this:

top:	A
	if !B then goto after
	D
	goto bottom
after:	C
	if !condition2 then goto top
bottom:	E

See what I'm getting at?  The source code is not trying to
express how the loop should be implemented.  It's trying to
express the flow control in a human-friendly form, and the
programmer should be confident that it will be implemented
in a machine-friendly form.  After all, isn't that the
point of a compiled language?  :-)

I know that most compilers do simple optimizations like this
anyway.  I'm just trying to differentiate between my mental image
of exit conditions and simple boolean flags.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.toronto.edu