for
SYNTAX:
for iteration_variable := initial_value to final_value do statement
or
for iteration_variable := initial_value downto final_value do statement
DESCRIPTION:
"for" is reserved word in all Pascal standards. It is used for introducing iterative loops during the execution. At the start of the loop the control variable set to the initial value then incremented by 1 after each execution step of the body of the "do" statement. The control variable should be an integer type. When the value of the control variable equals to the final value the execution continues at the next statement after the body of the "do". If the initial value and the final value are equal the loop executed ones. If the initial value higher than the final value the body of the "do" statement not executed.
In the second form of the command the control variable decremented by 1 in each cycle. The relation of the initial and final values are reversed accordingly.
The body of the "do" statement can contain other "for" cycles resulting nested loops. It is an error to set the value of the loop-control variable inside the loop. The code that violate that rule will compile and run - if there are no other errors - but the result will be unpredictable.
After the execution of the loop the value of the control variable is undefined. A proper code should not relay on that value.
STANDARDS: All
EXAMPLE:
var i,j,k:integer; vec:array[1..10] of integer; cube:array[1..10.1..10.1..10] of real; ... for i:= 1 to 10 do begin write('element [',i,']:? '); { prompt for the next value } readln(vec[i]); { read it } end; ....
for i:= 1 to 10 do { load data from "infile" } for j:= 1 to 10 do begin for k:= 1 to 10 do read(infile,cube[i,j,k]); readln(infile); { next line } end; close(infile);
SEE ALSO: do, while, repeat
________________________________
Comment this please.
miklos
According to Miklos Cserzo:
"for" is reserved word in all Pascal standards. It is used for introducing
^ a
iterative loops during the execution. At the start of the loop the control
^^^^^^^^^^^^^^^^^^^^ (When else?;-)
variable set to the initial value then incremented by 1 after each
^^^^^^^^^^^^^^^^ Here I am missing something like "with `to'".
execution step of the body of the "do" statement.
I wouldn't look upon this one as a separate "do statement". `do' is part of the `for' construction, and the iterated statement is best referred to by "the statement following `do'".
The control variable should be an integer type.
Nope. It must be of *ordinal* type. With extended syntax enabled, GPC also allows pointer types here.
It must be declared in the most inner enclosing block. According to BP, GPC also allows global variables here, or (as a GPC extension) any other lvalue.
When the value of the control variable equals to the final value the execution continues at the next statement after the body of the "do".
... of the "for statement" (see above).
If the initial value and the final value are equal the loop executed ones. If the initial value higher than the final value the body of the "do" statement not executed.
^ is
In the second form of the command
Better refer to it via `downto' instead of counting the forms we are describing.
the control variable decremented by 1 in each cycle. The relation of the initial and final values are reversed accordingly.
The body of the "do" statement can contain other "for" cycles resulting nested loops.
... can contain any valid Pascal statement including other "for" cycles ...
It is an error to set the value of the loop-control variable inside the loop. The code that violate that rule will compile and run - if there are no other errors - but the result will be unpredictable.
After the execution of the loop the value of the control variable is undefined.
While this is stated in ISO-10206 I have seen some ISO-7185 test programs that require the value to be <final_value>. Somebody knows definitly?
A proper code should not relay on that value.
STANDARDS: All
... except for the scope the control variable must be defined in.
EXAMPLE:
var i,j,k:integer; vec:array[1..10] of integer; cube:array[1..10.1..10.1..10] of real;
^ ^ , ,
I'd prefer an indentation like
var i,j,k:integer; vec:array[1..10] of integer; cube:array[1..10.1..10.1..10] of real;
My own way to write this would be
Var i, j, k: Integer; Vec: array [ 1..10 ] of Integer; Cube: array [ 1..10, 1..10, 1..10 ] of Real;
... but this is a matter of taste, of course.
... for i:= 1 to 10 do begin write('element [',i,']:? '); { prompt for the next value } readln(vec[i]); { read it } end;
Same here. My way to write this would have `begin' and `end' on a line of its own. In this case we have the GNU coding standards requiring the same for the braces in C, so we should use that convention.
As a compromise, I suggest
for i:= 1 to 10 do begin write('element [',i,']:? '); { prompt for the next value } readln(vec[i]); { read it } end;
while my own way would be
for i:= 1 to 10 do begin write ( 'element [ ',i,' ]: ' ); (* prompt for the next value *) readln ( vec [ i ] ); (* read it *) end (* for *);
....
Better only three dots, consistently.
In other examples, I have written:
[...]
What looks better?
[...]
There is one more important syntax for `for': set member iteration
for Ch in [ 'A'..'Z', 'a'..'z' ] do [...];
which is defined in ISO-10206 Extended Pascal only.
(You see: The "Standards" section is taking over ... ;-)
(You also see why I am so slow in writing documentation. ;-)-:
Greetings and thanks,
Peter
Peter Gerwinski a écrit:
It must be declared in the most inner enclosing block. According to BP, GPC also allows global variables here
A side remark: this is a very stupid BP extension, and it is a pity that gpc allows it (except of course in compatibility mode --borland-pascal). What are the advantages of this "extension": - saving a word of memory, but who cares nowadays of saving a single word of memory (I don't speak of saving storage for large arrays) - saving some keystrokes. Many beginners would think so ... What is the disavantage: just try the following small program to produce an infinite loop by "saving" the keystrokes to redeclare the variable "i" in the procedure "test". -------------------------- program essai;
var i:integer;
procedure test; begin for i:=1 to 2 do writeln(i) end;
begin for i:=1 to 4 do test; end. -------------------------- In real life programming finding such a bug in the middle of a few thousand lines program is usually a headache, especially because the fact that something goes wrong is not so obvious. And who has never used small identifiers as mute variables in for loops. Creators of pascal have "thought" to ways of avoiding stupids bugs. It seems that the ideal of many programmers is FORTRAN, whose "advantage" is to "save declarations of variables". Have you ever programmed with such an efficient bug generator? I begun with that.
On Thu, 4 Jun 1998, Maurice Lombardi wrote:
Peter Gerwinski a écrit:
It must be declared in the most inner enclosing block. According to BP, GPC also allows global variables here
A side remark: this is a very stupid BP extension, and it is a pity that gpc allows it (except of course in compatibility mode --borland-pascal). What are the advantages of this "extension":
- saving a word of memory, but who cares nowadays of saving a single
word of memory (I don't speak of saving storage for large arrays)
- saving some keystrokes. Many beginners would think so ...
What is the disavantage: just try the following small program to produce an infinite loop by "saving" the keystrokes to redeclare the variable "i" in the procedure "test".
This must be detected by the compiler; it is a "threatening statement" to the for-loop control variable, see section 6.9.4 (page 90) of the IEC-10206 extended pascal manual. There are also other threats to be detected, before gpc can be called a standard compiler.
I did not implement any of those, because it requires saving the context where each variable is used in order to detects it's use in some inner block, or to keep a hash of names that can currently be threatened and lookup this hash for each variable-access.
Juki jtv@hut.fi
program essai;
var i:integer;
procedure test; begin for i:=1 to 2 do writeln(i) end;
begin for i:=1 to 4 do test; end.
According to Maurice Lombardi:
A side remark: this is a very stupid BP extension, and it is a pity that gpc allows it (except of course in compatibility mode --borland-pascal). What are the advantages of this "extension":
- saving a word of memory, but who cares nowadays of saving a single
word of memory (I don't speak of saving storage for large arrays)
In fact this is not the case since local variables are only temporary but global ones require static memory.
- saving some keystrokes. Many beginners would think so ...
While I agree that this is a clear disadvantage I see other applications for global variables used in `for' loops: Think of a global state of the program (stored in a global variable) that goes through some "phases" during the loop. (In other words: I claim that there are some situations where the side effect is intended.)
program essai;
var i:integer;
procedure test; begin for i:=1 to 2 do writeln(i) end;
begin for i:=1 to 4 do test; end.
In real life programming finding such a bug in the middle of a few thousand lines program is usually a headache, especially because the fact that something goes wrong is not so obvious. [...]
In real life I would never call a global variable `i' or place a loop of this type in the main program, but I see your point: The compiler should help to detect the forgotten local declaration.
How to proceed?
* In --borland-pascal mode, GPC must emulate BP's behaviour (which is the case).
* In --extended-pascal mode, GPC must forbid expressions and non-local variables used as `for' control variables (which is the case).
* In default mode ... what to do?
In fact I don't care too much about `for' because I usually use `while' instead (because I need additional conditions to exit the loop), but I don't think that GPC should be really strict. Beginners must be *tought* that saving keystrokes is not a goal in programming; it is not desirable to disable valuable features of the compiler in order to avoid some minor traps.
What we must decide for each extension is whether it is a valuable feature or a major trap.
Peter