Re: Building blocks (Was: Design By Contract)

[mheaney@ni.net (Matthew Heaney)]

In article <5w3FnzA6KRR0Iwt+@treetop.demon.co.uk>, Paul Johnson
<Paul@treetop.demon.co.uk> wrote:

>I recall the great AT&T telephone crash in the late 80s (87?).  It was
>caused by a bug where a programmer had mistaken the scope of a "break"
>instruction, and hence miscalculated the target of the resulting jump.
>Now thats not a statistical experiment, but its a worrying data point.
>I wonder what would happen if Soloway's experiment were repeated with
>more complex problems involving nested loops.

In Ada, the programmer has control over the loop to which the exit applies,
by using loop labels; the C programmer can't do this without using an
explicit goto. 

A common idiom is to implement a finite state machine using loops, where
each loop represents a different state.  A "main" loop keeps the entire
thing going until termination is requested.  For example, I just wrote a
simple little test program to read in some data I typed in at the terminal,
and process it.  

begin
   Main:
   loop
      Put ("Enter: ");

      Get_Input:
      loop
         begin
            Get (Data);
            exit Get_Input;
         exception
            when End_Error =>
                exit Main;
            when Data_Error | Constraint_Error =>
                Skip_Line;
                Put ("Bad data; try again: ");
         end;
      end loop Get_Input;

      <process Data>
   end loop Main;

This is yet another example of the read-test-process loop idiom.

Think of the Get_Input loop as a state: you leave the state when you have
good data (and then go process it), or you leave the state (and the outer,
Main state too) because you're done with your testing (by pressing CNTL-D
on UNIX or CNTL-Z on VMS).  You stay in the Get_Input state as long as the
user enters bad data (wrong type or out-of-range).

Note how the exit statement explicitly identifies the loop to which it
applies: either Get_Input or Main.

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