abcscnuk@csuna.UUCP (Naoto Kimura) (12/14/88)
I have gotten into some pretty heated discussions regarding the
control variable in a for loop. I was arguing that it was a bad idea to
use a global variable, in fact it is an error to do so. I'm arguing
from the ISO standard, while the people I was arguing against were going
by specific implementations that allowed it.
Should the use of a relatively global variable be allowed as a
control variable for a for loop ? Should the use of a passed parameter
be allowed as a control variable ? I say no to both of these.
One person that I got into an argument with said that the behavior
should be that you can change a control variable, but should not have
any effect on the loop itself. I don't think that is reasonable.
Consider the confusion over what the variable 'i' should contain when
you use it in several procedures as control variables for a for loop.
I'd like to know how you feel about the behavior of the following
program. What should the output be (if the compiler even lets this
code through) ?
program nonsense(input,output);
var
i : integer;
procedure barf;
begin
for i := 1 to 10 do
write(i:3);
write(' i=',i)
end;
procedure ack;
begin
for i := 1 to 10 do begin
write('i=',i:2,' ');
barf;
writeln
end
end;
begin
for i := 1 to 10 do
ack
end.
//-n-\\ Naoto Kimura
_____---=======---_____ (csun!csuna!abcscnuk)
====____\ /.. ..\ /____====
// ---\__O__/--- \\ Enterprise... Surrender or we'll
\_\ /_/ send back your *&^$% tribbles !!abcscnuk@csuna.UUCP (Naoto Kimura) (12/14/88)
I have only found one compiler that handles the program I
gave in my previous message correctly. It is the pascal
compiler (vers 4) found on the CDC Cyber 750 here at CSUN.
The compiler should give the error message "Control variable
must be local."
//-n-\\ Naoto Kimura
_____---=======---_____ (csun!csuna!abcscnuk)
====____\ /.. ..\ /____====
// ---\__O__/--- \\ Enterprise... Surrender or we'll
\_\ /_/ send back your *&^$% tribbles !!
P.S.: For the benifit of those who missed my last posting...
program nonsense(input,output);
var
i : integer;
procedure barf;
begin
for i := 1 to 10 do
write(i:3);
write(' i=',i)
end;
procedure ack;
begin
for i := 1 to 10 do begin
write('i=',i:2,' ');
barf;
writeln('i=',i:2)
end
end;
begin
for i := 1 to 10 do
ack
end.spector@brillig.umd.edu (Lee Spector) (12/15/88)
In article <1440@csuna.UUCP> abcscnuk@csuna.UUCP (Naoto Kimura) writes: > >program nonsense(input,output); > var > i : integer; > > procedure barf; > begin > for i := 1 to 10 do > write(i:3); > write(' i=',i) (****) > end; > > procedure ack; > begin > for i := 1 to 10 do begin > write('i=',i:2,' '); > barf; > writeln('i=',i:2) > end > end; > >begin > for i := 1 to 10 do > ack >end. (The question is: what SHOULD this do and what DOES it do in implementation X.) I ran this on Berkeley pascal on a big Vax here at U. MD. The compiler did not complain. I don't like what resulted from the last line in barf. (the one I marked (****) What it did was to always print 10. This is not consistent with any rules for access to i that I can formulate. I thought I understood how loop counters were supposed to work, but now I'm quite confused and I'd appreciate any clarification anyone can offer. (If all references to i are to the global - even asssuming that the values that a loop counter takes on are precomputed and that the loop variable is set to the proper value at the top of the loop - then the last line in ack should also always print 10. If entering a loop pushes a new activation record then the line in question (****) refers to an uninitialized variable; this is not the case as the result is the same even if you add a statement to initialize the global.) (the output was the following repeated 10 times:) i= 1 1 2 3 4 5 6 7 8 9 10 i= 10i= 1 i= 2 1 2 3 4 5 6 7 8 9 10 i= 10i= 2 i= 3 1 2 3 4 5 6 7 8 9 10 i= 10i= 3 i= 4 1 2 3 4 5 6 7 8 9 10 i= 10i= 4 i= 5 1 2 3 4 5 6 7 8 9 10 i= 10i= 5 i= 6 1 2 3 4 5 6 7 8 9 10 i= 10i= 6 i= 7 1 2 3 4 5 6 7 8 9 10 i= 10i= 7 i= 8 1 2 3 4 5 6 7 8 9 10 i= 10i= 8 i= 9 1 2 3 4 5 6 7 8 9 10 i= 10i= 9 i=10 1 2 3 4 5 6 7 8 9 10 i= 10i=10
kent@swrinde.swri.edu (Kent D. Polk) (12/15/88)
In article <1439@csuna.UUCP> abcscnuk@csun.UUCP (Naoto Kimura) writes: > > I have gotten into some pretty heated discussions regarding the >control variable in a for loop. I was arguing that it was a bad idea to >use a global variable, in fact it is an error to do so. I'm arguing >from the ISO standard, while the people I was arguing against were going >by specific implementations that allowed it. > > Should the use of a relatively global variable be allowed as a >control variable for a for loop ? Should the use of a passed parameter >be allowed as a control variable ? I say no to both of these. > Try porting a program written in Turbo Pascal which makes use of these interesting 'features'. I have always used Pascal compilers which follow the ISO standard in this respect - Forcing the use of local variables for control loop variables, & have NEVER seen an instance where it was necessary or even desirable (to me). The coding standards at places I have worked would also not allow it, and I support those decisions. I have thrown out work submitted to me which implemented such features because it costs ($$$) to maintain such software. ======================================================================== Kent Polk - Southwest Research Institute |>Insert Standard< {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent|> Disclaimer < ========================================================================
art@buengc.BU.EDU (A. R. Thompson) (12/15/88)
In article <1439@csuna.UUCP> abcscnuk@csun.UUCP (Naoto Kimura) writes: > > I have gotten into some pretty heated discussions regarding the >control variable in a for loop. I was arguing that it was a bad idea to >use a global variable, in fact it is an error to do so. I'm arguing >from the ISO standard, while the people I was arguing against were going >by specific implementations that allowed it. Which demonstrates why you should never allow a particular implementation to define a language. Only the standard, or lacking a standard, the official "report" of the creator of the language. > > Should the use of a relatively global variable be allowed as a >control variable for a for loop ? Should the use of a passed parameter >be allowed as a control variable ? I say no to both of these. Absolutely not. The standard is quite clear on this. In fact, when the standard was being written a desire was expressed to force the control variable to be local to the for statement itself. Try defining that. > > One person that I got into an argument with said that the behavior >should be that you can change a control variable, but should not have >any effect on the loop itself. I don't think that is reasonable. >Consider the confusion over what the variable 'i' should contain when >you use it in several procedures as control variables for a for loop. How can you change the control variable without having any effect on the loop itself? If they want to fiddle with the control variable, I suggest they use the while and repeat statements. That's what they're for. > > I'd like to know how you feel about the behavior of the following >program. What should the output be (if the compiler even lets this >code through) ? > The following listing shows what the Encore Pascal-2 compiler "thinks" of this program. You're right and your friends are wrong. Pascal-2 3.01 Encore UMAX 14-Dec-88 3:47 PM Page 1-1 nonsense.p 1 2 program nonsense(input,output); 3 var 4 i : integer; 5 6 procedure barf; 7 begin 8 for i := 1 to 10 do ^108 *** 108: FOR-loop control variable must be declared at this level 9 write(i:3); 10 write(' i=',i) 11 end; 12 13 procedure ack; 14 begin 15 for i := 1 to 10 do begin ^108 *** 108: FOR-loop control variable must be declared at this level 16 write('i=',i:2,' '); 17 barf; 18 writeln 19 end 20 end; 21 22 begin 23 for i := 1 to 10 do 24 ack 25 end. 26 Invocation line: -list nonsense.p *** There were 2 lines with errors detected ***
garnett@a.cs.okstate.edu (John Garnett) (12/15/88)
From article <1440@csuna.UUCP>, by abcscnuk@csuna.UUCP (Naoto Kimura): > I have only found one compiler that handles the program I > gave in my previous message correctly. It is the pascal > compiler (vers 4) found on the CDC Cyber 750 here at CSUN. > The compiler should give the error message "Control variable > must be local." > Isn't it also true that the value of 'i' will be undefined following the termination of the loop contained in procedure 'barf'? If this is the case, then the loop contained in 'ack' should bomb after the first call to 'barf' (assuming the global variable 'i' is allowed as a lcv) John Garnett Computing and Information Sciences Oklahoma State University Email: garnett@a.cs.okstate.edu Stillwater, Oklahoma
chl@r1.uucp (Charles Lindsey) (12/16/88)
In article <1440@csuna.UUCP> abcscnuk@csuna.UUCP (Naoto Kimura) writes: >I have only found one compiler that handles the program I >gave in my previous message correctly. It gives a Warning with the Sun Pascal compiler, but only if you compile with the -s (for standard) option. I am not impressed.
garnett%A.CS.OKSTATE.EDU%CUNYVM.CUNY.EDU@cunyvm.cu (John Garnett) (12/17/88)
From article <1440@csuna.UUCP>, by abcscnuk@csuna.UUCP (Naoto Kimura): > I have only found one compiler that handles the program I > gave in my previous message correctly. It is the pascal > compiler (vers 4) found on the CDC Cyber 750 here at CSUN. > The compiler should give the error message "Control variable > must be local." > Isn't it also true that the value of 'i' will be undefined following the termination of the loop contained in procedure 'barf'? If this is the case, then the loop contained in 'ack' should bomb after the first call to 'barf' (assuming the global variable 'i' is allowed as a lcv) John Garnett Computing and Information Sciences Oklahoma State University Email: garnett@a.cs.okstate.edu Stillwater, Oklahoma
art%BUENGC.BU.EDU%CUNYVM.CUNY.EDU@cunyvm.cuny. (A. R. Thompson) (12/17/88)
In article <1439@csuna.UUCP> abcscnuk@csun.UUCP (Naoto Kimura) writes: > > I have gotten into some pretty heated discussions regarding the >control variable in a for loop. I was arguing that it was a bad idea to >use a global variable, in fact it is an error to do so. I'm arguing >from the ISO standard, while the people I was arguing against were going >by specific implementations that allowed it. Which demonstrates why you should never allow a particular implementation to define a language. Only the standard, or lacking a standard, the official "report" of the creator of the language. > > Should the use of a relatively global variable be allowed as a >control variable for a for loop ? Should the use of a passed parameter >be allowed as a control variable ? I say no to both of these. Absolutely not. The standard is quite clear on this. In fact, when the standard was being written a desire was expressed to force the control variable to be local to the for statement itself. Try defining that. > > One person that I got into an argument with said that the behavior >should be that you can change a control variable, but should not have >any effect on the loop itself. I don't think that is reasonable. >Consider the confusion over what the variable 'i' should contain when >you use it in several procedures as control variables for a for loop. How can you change the control variable without having any effect on the loop itself? If they want to fiddle with the control variable, I suggest they use the while and repeat statements. That's what they're for. > > I'd like to know how you feel about the behavior of the following >program. What should the output be (if the compiler even lets this >code through) ? > The following listing shows what the Encore Pascal-2 compiler "thinks" of this program. You're right and your friends are wrong. Pascal-2 3.01 Encore UMAX 14-Dec-88 3:47 PM Page 1-1 nonsense.p 1 2 program nonsense(input,output); 3 var 4 i : integer; 5 6 procedure barf; 7 begin 8 for i := 1 to 10 do ^108 *** 108: FOR-loop control variable must be declared at this level 9 write(i:3); 10 write(' i=',i) 11 end; 12 13 procedure ack; 14 begin 15 for i := 1 to 10 do begin ^108 *** 108: FOR-loop control variable must be declared at this level 16 write('i=',i:2,' '); 17 barf; 18 writeln 19 end 20 end; 21 22 begin 23 for i := 1 to 10 do 24 ack 25 end. 26 Invocation line: -list nonsense.p *** There were 2 lines with errors detected ***
spector%BRILLIG.UMD.EDU%CUNYVM.CUNY.EDU@cunyvm.cuny (Lee Spector) (12/17/88)
In article <1440@csuna.UUCP> abcscnuk@csuna.UUCP (Naoto Kimura) writes: > >program nonsense(input,output); > var > i : integer; > > procedure barf; > begin > for i := 1 to 10 do > write(i:3); > write(' i=',i) (****) > end; > > procedure ack; > begin > for i := 1 to 10 do begin > write('i=',i:2,' '); > barf; > writeln('i=',i:2) > end > end; > >begin > for i := 1 to 10 do > ack >end. (The question is: what SHOULD this do and what DOES it do in implementation X.) I ran this on Berkeley pascal on a big Vax here at U. MD. The compiler did not complain. I don't like what resulted from the last line in barf. (the one I marked (****) What it did was to always print 10. This is not consistent with any rules for access to i that I can formulate. I thought I understood how loop counters were supposed to work, but now I'm quite confused and I'd appreciate any clarification anyone can offer. (If all references to i are to the global - even asssuming that the values that a loop counter takes on are precomputed and that the loop variable is set to the proper value at the top of the loop - then the last line in ack should also always print 10. If entering a loop pushes a new activation record then the line in question (****) refers to an uninitialized variable; this is not the case as the result is the same even if you add a statement to initialize the global.) (the output was the following repeated 10 times:) i= 1 1 2 3 4 5 6 7 8 9 10 i= 10i= 1 i= 2 1 2 3 4 5 6 7 8 9 10 i= 10i= 2 i= 3 1 2 3 4 5 6 7 8 9 10 i= 10i= 3 i= 4 1 2 3 4 5 6 7 8 9 10 i= 10i= 4 i= 5 1 2 3 4 5 6 7 8 9 10 i= 10i= 5 i= 6 1 2 3 4 5 6 7 8 9 10 i= 10i= 6 i= 7 1 2 3 4 5 6 7 8 9 10 i= 10i= 7 i= 8 1 2 3 4 5 6 7 8 9 10 i= 10i= 8 i= 9 1 2 3 4 5 6 7 8 9 10 i= 10i= 9 i=10 1 2 3 4 5 6 7 8 9 10 i= 10i=10
art@buengc.BU.EDU (A. R. Thompson) (12/18/88)
In article <17855@adm.BRL.MIL> spector%BRILLIG.UMD.EDU@cunyvm.cuny.edu (Lee Spector) writes: >[text of program "nonsense" deleted. >(The question is: what SHOULD this do and what DOES it do in implementation > X.) > >I ran this on Berkeley pascal on a big Vax here at U. MD. The compiler did not >complain. I don't like what resulted from the last line in barf. >(the one I marked (****) What it did was to always print 10. >This is not consistent with any rules for access to i that I can formulate. >I thought I understood how loop counters were supposed to work, but now >I'm quite confused and I'd appreciate any clarification anyone can offer. Since the program is not legal Pascal, you really can't predict what it "should" do because you can't appeal to the language definition for guidance. It's an illegal program pure and simple.
randy@m2xenix.UUCP (Randy Bush) (12/18/88)
Conjecture and testing aginst particular implementations (other than ours, of
course:-) may be amusing, but have little to do with the definition of the
language. I recommend the standard itself, accompanied by "Standard Pascal
User Reference Manual" by Doug Cooper.
The control variable of a FOR loop may not be 'relatively global'. I.e. it
must be declared in the variable declaration part of the program, procedure,
or function in which it is used.
The interesting, and unexpected, restriction is that it may not be threatened
by use within an enclosed procedure/function. The following is not legal:
PROGRAM foo; (* excuse keyword capitalization. i am a modulan *)
PROCEDURE fee;
VAR i : INTEGER;
PROCEDURE bar;
BEGIN
i := 42 (* this assignment threatens the control variable *)
END;
BEGIN (* fee *)
FOR i := 0 TO 42 DO
END;
BEGIN (* foo *)
END.
A correct Pascal compiler must detect the above error. Yes, that test is in
the Pascal Validation Suite.
--
{ mcvax!uunet!oresoft, tektronix!percival!qiclab } !m2xenix!randy Randy Bushart@buengc.BU.EDU (A. R. Thompson) (12/19/88)
In article <169@m2xenix.UUCP> randy@m2xenix.UUCP (Randy Bush) writes: >Conjecture and testing aginst particular implementations (other than ours, of >course:-) may be amusing, but have little to do with the definition of the >language. I recommend the standard itself, accompanied by "Standard Pascal >User Reference Manual" by Doug Cooper. Another goodd reference is "Pascal. User Manual and Report" 3rd ed. Jensen and Wirth, revised by Mickel and Miner. > >The interesting, and unexpected, restriction is that it may not be threatened >by use within an enclosed procedure/function. The following is not legal: > I'm not quite sure what is so "unexpected" in the restriction that there may not be an assigning reference to the control variable in a for statement. The for statement is intended as a strictly sequential way of stepping through a succesion of statements (often array references). If you want to make assigning references to the control variable in a looping statement, you should use either a while statement or a repeat statement. That's what they are for (so to speak).
gsarff@meph.UUCP (Gary Sarff) (12/20/88)
In article <4267@okstate.UUCP> garnett@a.cs.okstate.edu (John Garnett) >From article <1440@csuna.UUCP>, by abcscnuk@csuna.UUCP (Naoto Kimura): >> I have only found one compiler that handles the program I >> gave in my previous message correctly. It is the pascal >> compiler (vers 4) found on the CDC Cyber 750 here at CSUN. >> The compiler should give the error message "Control variable >> must be local." >> > >Isn't it also true that the value of 'i' will be undefined following the >termination of the loop contained in procedure 'barf'? If this is the >case, then the loop contained in 'ack' should bomb after the first call >to 'barf' (assuming the global variable 'i' is allowed as a lcv) Depends on how the compiler makes 'i' undefined, if there is some way to put a NaN (not a number) in i for example. For the record my compiler Pascal 4.4 on Wicat Systems computers (68020 based) also gives an error message, "for loop index must be local" and won't compile the program. ------------------------------------------------------------------------ "Those whom the gods would destroy, they first make mad" He who steals my core-dump, steals trash
abcscnuk%CSUNA.UUCP%CUNYVM.CUNY.EDU@cunyvm.cuny.ed (Naoto Kimura) (12/21/88)
I have gotten into some pretty heated discussions regarding the
control variable in a for loop. I was arguing that it was a bad idea to
use a global variable, in fact it is an error to do so. I'm arguing
from the ISO standard, while the people I was arguing against were going
by specific implementations that allowed it.
Should the use of a relatively global variable be allowed as a
control variable for a for loop ? Should the use of a passed parameter
be allowed as a control variable ? I say no to both of these.
One person that I got into an argument with said that the behavior
should be that you can change a control variable, but should not have
any effect on the loop itself. I don't think that is reasonable.
Consider the confusion over what the variable 'i' should contain when
you use it in several procedures as control variables for a for loop.
I'd like to know how you feel about the behavior of the following
program. What should the output be (if the compiler even lets this
code through) ?
program nonsense(input,output);
var
i : integer;
procedure barf;
begin
for i := 1 to 10 do
write(i:3);
write(' i=',i)
end;
procedure ack;
begin
for i := 1 to 10 do begin
write('i=',i:2,' ');
barf;
writeln
end
end;
begin
for i := 1 to 10 do
ack
end.
//-n-\\ Naoto Kimura
_____---=======---_____ (csun!csuna!abcscnuk)
====____\ /.. ..\ /____====
// ---\__O__/--- \\ Enterprise... Surrender or we'll
\_\ /_/ send back your *&^$% tribbles !!abcscnuk%CSUNA.UUCP%CUNYVM.CUNY.EDU@cunyvm.cuny.ed (Naoto Kimura) (12/21/88)
I have only found one compiler that handles the program I
gave in my previous message correctly. It is the pascal
compiler (vers 4) found on the CDC Cyber 750 here at CSUN.
The compiler should give the error message "Control variable
must be local."
//-n-\\ Naoto Kimura
_____---=======---_____ (csun!csuna!abcscnuk)
====____\ /.. ..\ /____====
// ---\__O__/--- \\ Enterprise... Surrender or we'll
\_\ /_/ send back your *&^$% tribbles !!
P.S.: For the benifit of those who missed my last posting...
program nonsense(input,output);
var
i : integer;
procedure barf;
begin
for i := 1 to 10 do
write(i:3);
write(' i=',i)
end;
procedure ack;
begin
for i := 1 to 10 do begin
write('i=',i:2,' ');
barf;
writeln('i=',i:2)
end
end;
begin
for i := 1 to 10 do
ack
end.randy@m2xenix.UUCP (Randy Bush) (12/21/88)
In article <1712@buengc.BU.EDU> art@buengc.bu.edu (A. R. Thompson) writes: >In article <169@m2xenix.UUCP> randy@m2xenix.UUCP (Randy Bush) writes: >>The interesting, and unexpected, restriction is that it may not be threatened >>by use within an enclosed procedure/function. The following is not legal: > >If you want to make assigning references to the control variable in a looping >statement, you should use either a while statement or a repeat statement. >That's what they are for (so to speak). Please peruse the example again. There was no assignment to the control variable during the dynamic execution of the FOR statement. In fact, the procedure containing the threat is never called, nor is there any code in the FOR's statement sequence. The restriction on 'threatening' (to forbid what is actually a non-threat) in the example is a sop to the compiler writer. Without the restriction, it is easy (albeit ugly) to write real threats that are quite hard to detect. Again, (a simpler case of) the illegal example: PROGRAM foo; VAR i : INTEGER; PROCEDURE fee; BEGIN i := 42 (* this illegal assignment 'threatens' i *) END (* fee *); BEGIN (* foo *) (* whereas i := 42 here would be legal *) FOR i := 0 TO 42 DO END. BTW, the ISO Modula-2 committee is leaning toward a similar position. -- { mcvax!uunet!oresoft, tektronix!percival!qiclab } !m2xenix!randy Randy Bush
markh@csd4.milw.wisc.edu (Mark William Hopkins) (12/22/88)
In article <1439@csuna.UUCP> abcscnuk@csun.UUCP (Naoto Kimura) writes: > > I have gotten into some pretty heated discussions regarding the >control variable in a for loop. I was arguing that it was a bad idea to >use a global variable, in fact it is an error to do so. I'm arguing >from the ISO standard, while the people I was arguing against were going >by specific implementations that allowed it. You are right about its illegality. In any case, a programmer has no business cluttering up the "main program" with extraneous variables. It makes the program more difficult to read, and write. Some people even initialize the counters (gag). I think the only sensible approach to defining for loops is to make it equivalent to the corresponding while loop, much as in C. Example: for I := A to B do S equals I := A; while I <= B do begin S; if I < B then I := succ(I) end an optimized version would be this: I := A; while I < B do begin S; I := succ(I) end; if I = B then S > > I'd like to know how you feel about the behavior of the following >program. What should the output be (if the compiler even lets this >code through) ? > >program nonsense(input,output); > var > i : integer; > > procedure barf; > begin > for i := 1 to 10 do > write(i:3); > write(' i=',i) > end; According to the definition I posed above, the output would be: 1 2 3 4 5 6 7 8 9 10 i= 10. (assuming that the default integer field width is 10.) My definition makes the variable stay at 10. In general, this kind of thing is necessary if you are going to be able to handle for loops with subrange types and enumerated types correctly. > > procedure ack; > begin > for i := 1 to 10 do begin > write('i=',i:2,' '); > barf; > writeln > end > end; i= 1 1 2 3 4 5 6 7 8 9 10 i= 10.<eoln> The only real argument here is that "barf" should be barf(i) (or i := barf). The missing parameter is at fault for the "unpredictability more so than the "faulty" counter. > >begin > for i := 1 to 10 do > ack >end. Same as ack, according to my definition above. Same argument too: "ack" should be ack(i), or better yet, i := ack. It's the unnecessary global variables that present the problem, not the counters.
art@buengc.BU.EDU (A. R. Thompson) (12/23/88)
In article <170@m2xenix.UUCP> randy@m2xenix.UUCP (Randy Bush) writes: >In article <1712@buengc.BU.EDU> art@buengc.bu.edu (A. R. Thompson) writes: >>In article <169@m2xenix.UUCP> randy@m2xenix.UUCP (Randy Bush) writes: >>>The interesting, and unexpected, restriction is that it may not be threatened >>>by use within an enclosed procedure/function. The following is not legal: >> >>If you want to make assigning references to the control variable in a looping >>statement, you should use either a while statement or a repeat statement. >>That's what they are for (so to speak). > >Please peruse the example again. There was no assignment to the control >variable during the dynamic execution of the FOR statement. In fact, the >procedure containing the threat is never called, nor is there any code in >the FOR's statement sequence. Yes, but there was more to the question than just the example. The poster raised a question wrt assignments to the control variable within the body of the for statement. Many people I have encountered want to do this. It's not just wrong, it's downright dangerous.
art@buengc.BU.EDU (A. R. Thompson) (12/23/88)
In article <45@csd4.milw.wisc.edu> markh@csd4.milw.wisc.edu (Mark William Hopkins) writes: >In article <1439@csuna.UUCP> abcscnuk@csun.UUCP (Naoto Kimura) writes: > >You are right about its illegality. In any case, a programmer has no business >cluttering up the "main program" with extraneous variables. It makes the >program more difficult to read, and write. >Some people even initialize the counters (gag). > >I think the only sensible approach to defining for loops is to make it >equivalent to the corresponding while loop, much as in C. Example: > >for I := A to B do S equals I := A; > while I <= B do begin > S; > if I < B then I := succ(I) > end > >an optimized version would be this: > > I := A; > while I < B do begin S; I := succ(I) end; > if I = B then S > >> >> I'd like to know how you feel about the behavior of the following >>program. What should the output be (if the compiler even lets this >>code through) ? >> > >>program nonsense(input,output); >> var >> i : integer; >> >> procedure barf; >> begin >> for i := 1 to 10 do >> write(i:3); >> write(' i=',i) >> end; > >According to the definition I posed above, the output would be: > > 1 2 3 4 5 6 7 8 9 10 i= 10. > >(assuming that the default integer field width is 10.) Ah, but since you've already established that it's an illegal program you can no longer predict what will happen. That's strictly up to the compiler writer (who is duty bound to report the error and refuse to generate executable code). Secondarily, while your definition is the proper way to define the effect of the for statement it allows the control variable to be defined after completion of the while statement. The control variable is required to be undefined upon completion of the for statement.
markh@csd4.milw.wisc.edu (Mark William Hopkins) (12/23/88)
In article <1771@buengc.BU.EDU> art@buengc.bu.edu (A. R. Thompson) writes: >In article <45@csd4.milw.wisc.edu> markh@csd4.milw.wisc.edu (Mark William Hopkins) writes: <MY PROPOSED DEFINITION OF A FOR LOOP> >> >>for I := A to B do S equals I := A; >> while I <= B do begin >> S; >> if I < B then I := succ(I) >> end >> <COMMENTING ON THE RESULTS OF APPLYING THIS DEFINITION TO A SAMPLE PROGRAM>: > >Ah, but since you've already established that it's an illegal program you >can no longer predict what will happen. That's strictly up to the >compiler writer (who is duty bound to report the error and refuse to >generate executable code). Secondarily, while your definition is the >proper way to define the effect of the for statement it allows the control >variable to be defined after completion of the while statement. The >control variable is required to be undefined upon completion of the for >statement. The point I was making is that it is much easier on all counts to define the for loop as a while loop and not place any restrictions on the control variable. The real problem with the program example brought up previously was that it used global variables, and I don't think Pascal should have allowed for them at all. The for loop was merely a red herring.
ags@s.cc.purdue.edu (Dave Seaman) (12/27/88)
In article <1771@buengc.BU.EDU> art@buengc.bu.edu (A. R. Thompson) writes: >Ah, but since you've already established that it's an illegal program you >can no longer predict what will happen. That's strictly up to the >compiler writer (who is duty bound to report the error and refuse to >generate executable code). Not so. The compiler writer is free to do whatever he likes, provided the accompanying documentation describes the types of errors that are not reported by the compiler. -- Dave Seaman ags@j.cc.purdue.edu
art@buengc.BU.EDU (A. R. Thompson) (12/29/88)
In article <3693@s.cc.purdue.edu> ags@s.cc.purdue.edu (Dave Seaman) writes: >In article <1771@buengc.BU.EDU> art@buengc.bu.edu (A. R. Thompson) writes: >>Ah, but since you've already established that it's an illegal program you >>can no longer predict what will happen. That's strictly up to the >>compiler writer (who is duty bound to report the error and refuse to >>generate executable code). > >Not so. The compiler writer is free to do whatever he likes, provided the >accompanying documentation describes the types of errors that are not >reported by the compiler. > While the standard may allow this I take exception to it in cases like this.
art@buengc.BU.EDU (A. R. Thompson) (12/29/88)
Hi Al! I read comp.lang.pascal, but presently can't respond directly. I just noticed the following: ----------------------------------- In article <3693@s.cc.purdue.edu> ags@s.cc.purdue.edu (Dave Seaman) writes: >In article <1771@buengc.BU.EDU> art@buengc.bu.edu (A. R. Thompson) writes: >>Ah, but since you've already established that it's an illegal program you >>can no longer predict what will happen. That's strictly up to the >>compiler writer (who is duty bound to report the error and refuse to >>generate executable code). > >Not so. The compiler writer is free to do whatever he likes, provided the >accompanying documentation describes the types of errors that are not >reported by the compiler. > While the standard may allow this I take exception to it in cases like this. ----------------------------------- In fact, the compiler writer is NOT "free to do whatever he likes" if she is writing a standards-conforming compiler. Most of the restrictions under discussion are not "errors" (as defined in the standard), and thus a conforming processor (compiler) MUST detect violations of those restrictions. It is only those restrictions explicitly defined by the standard as "errors" or "implementation-dependent" for which detection is optional. Please forward this to the net. Regards, Jim Miner
ags@s.cc.purdue.edu (Dave Seaman) (12/29/88)
[quoting my earlier statement] >>Not so. The compiler writer is free to do whatever he likes, provided the >>accompanying documentation describes the types of errors that are not >>reported by the compiler. In article <1806@buengc.BU.EDU> art@buengc.bu.edu (A. R. Thompson) [actually Jim Miner] writes: >In fact, the compiler writer is NOT "free to do whatever he likes" if she >is writing a standards-conforming compiler. Most of the restrictions under >discussion are not "errors" (as defined in the standard), and thus a >conforming processor (compiler) MUST detect violations of those >restrictions. It is only those restrictions explicitly defined by the >standard as "errors" or "implementation-dependent" for which detection is >optional. The context of my earlier statement has been lost. We were discussing programs that make use of the control variable of a FOR loop after a normal exit. The standard says that such a control variable "becomes undefined" upon loop termination. The standard also says that "it is an error" for an expression to reference an undefined variable. The standard further says that errors need not be reported, provided the accompanying documentation points out that fact. Therefore, I stand by my original statement. -- Dave Seaman ags@j.cc.purdue.edu
dik@cwi.nl (Dik T. Winter) (01/13/89)
In article <00056@meph.UUCP> gsarff@meph.UUCP (Gary Sarff) writes: > In article <4267@okstate.UUCP> garnett@a.cs.okstate.edu (John Garnett) > >Isn't it also true that the value of 'i' will be undefined following the > >termination of the loop contained in procedure 'barf'? > > Depends on how the compiler makes 'i' undefined, if there is some way to > put a NaN (not a number) in i for example. But a compiler is not required to take action to make 'i' undefined. Undefined is just that: the standard does not predict the value present in 'i' after termination of the loop. It may be the value before start of the loop; the last value assigned; the same plus 1; NaN; 24723; or whatever you fancy. -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax