Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!mailrus!tut.cis.ohio-state.edu!uwmcsd1!csd4.milw.wisc.edu!markh
From: markh@csd4.milw.wisc.edu (Mark William Hopkins)
Newsgroups: comp.lang.modula2
Subject: The semantics of the for-loop
Message-ID: <5571@uwmcsd1.UUCP>
Date: 16 Apr 88 23:43:29 GMT
Sender: daemon@uwmcsd1.UUCP
Reply-To: markh@csd4.milw.wisc.edu (Mark William Hopkins)
Organization: University of Wisconsin-Milwaukee
Lines: 28
Summary: Artfully sidetracking minor issues


     The best way out of the difficulties associated with the for-loop is
to define it.  I would suggest the following definition:

FOR I := A TO B DO       ==      I := A;
 <Statement Sequence>            WHILE I < B DO 
END                                <Statement Sequence>;
                                   I := I + 1
                                 END;
				 IF I = B THEN
				   <Statment Sequence>
                                 ENDIF

This set-up makes I come out of the loop with the value B.

     An alternative, which is closer to the original intent of making
the "control variable" a LOCAL VARIABLE of the FOR-LOOP, is the
following:

FOR I := A TO B DO       =  PFOR(A, B) where PFOR is declared as the procedure
   <Statement Sequence>     PROCEDURE PFOR( A, B : TypeName);
			    VAR I : TypeName;
END                         BEGIN
			       Enclose the statements above
                            END

This does not make the troubles associated with I disappear, but it does
make the restrictions on I less ad-hoc.