Re: Building blocks (Was: Design By Contract)

[mheaney@ni.net (Matthew Heaney)]

In article <PdRYMWAQ1cN0Iw4X@treetop.demon.co.uk>, Paul Johnson
<Paul@treetop.demon.co.uk> wrote:

>>(One of the while-loop problem is that for a tidy
>>record processing program you have to write
>>       record = file.read()
>>       Do while(~file.eof())
>>               thing.accept(record)
>>               record = file.read()
>>       End while
>>)
>
>I know that this was an aside, but it still puzzles me.  Surely it will
>be wrong if the file is empty: there will be no record to read.  The
>correct version (in Eiffel) would be
>
>   from file.open("foo") until file.eof loop
>      thing.accept (file.record)
>   end -- loop
>
>If you have to read a dummy record before file.eof becomes valid then
>you have a badly designed file object.

That's the idiom in Ada too:

while not End_Of_File (F) loop
   Read (F, X);
   <do something with X>;
end loop;

I think the original example, though, was this: read some numbers from the
user interactively, process each one at a time, and stop processing when
the user enters a zero.  In Ada, it would be 

loop
   Read (N);
   exit when N = 0;
   <do something with N>;
end loop;

This is a very clean solution, and in the Soloway paper, they showed that
there were fewer errors using this loop structure compared to a loop which
disallows an exit from the middle.  Something like:

Read (N);
while N /= 0 loop
   <do something with N>
   Read (N);
end loop;

The issue here is that the read statement must be written twice.  Exiting
from the middle is a more natural idiom for certain problems. 

So don't assume that there's a "badly designed" file, because we might not
be literally talking about a file.  That the loop termination depends on
what you've read (the "dummy" value) is a common occurrence, and the
simplest loop idiom in this case is:

loop
   <get value>
   exit when <value is special>
   <process value>
end loop;

A while loop is more complex and error prone solution for this type of
problem.  Soloway showed that there was a statistically significant
difference between two populations, one using a test-at-the-top, and the
other using a test-in-the-middle, with the latter group having fewer
errors.  The reference is:

Coginitive Strategies and Looping Constructs: An Empirical Study
Elliot Soloway et al
CACM, Vol. 26, No. 11, Nov 83, p. 853 - 860


A typical example of termination depending on input is a scanner.  If
you're scanning an identifier (say), then you exit when you've read some
whitespace:

Scan_Identifier:
loop
   <get character>
   exit Scan_Identifier when <char is whitespace>
   <buffer char>
end loop Scan_Identifier;

<process Identifier token>

Another common idiom is a linear search.  When you find the item you're
looking for, bail out:

Find_Item:
declare
   Found : Boolean := False;
   Position : Positive range Items'Range;
begin
   for Index in Items'Range loop
      if Items (Index) = Item then
         Position := Index;
         Found := True;

         exit;
      end if;
   end loop;

   if Found then
      <do something>
   else
      <do something else>
   end if;
end Find_Item;

Exiting from the middle of a loop also shows up in functions as an early return:

function Position (Items : Item_Array; Item : T) return Natural is
begin
   for Index in Items'Range loop
      if Items (Index) = Item then
         return Index;
      end if;
   end loop;

   return 0;  -- means Item not found
end;

In none of these cases is the "file" badly designed.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271