Please make your language more freedom

[mercurhyo]

problem is GDB ... would the current debugger be able to follow my little Big Pascalish Mind
ha ha ha. I don't know

[Zoran]

If the loop was terminated prematurely with an exception or a break statement, the loop variable retains the value it had when the loop was exited.

So there a cases where the loop variable can be accessed after the loop.

Using this "feature" in real code is an ugly hack. Yes, ugly hacks are allowed in Pascal too.
If you want to make the code maintainer's life difficult (don't forget, it will often be yourself, too), you can do it in Pascal too.
On the other hand, if you want to write nice and readable code, you can do it in C and C++ too.

A hacker will write

Code: C  [Select][+][-]

1. j = ++i;

in one place and

Code: C  [Select][+][-]

1. j = i++;

in the other.

Unlike the hacker, a programmer will write

Code: C  [Select][+][-]

1. ++i;
2. j = i;

or

Code: C  [Select][+][-]

1. j = i;
2. ++i;

And the maintainer will easily see what the programme does.

[mercurhyo]

--i++ whatever.. why ++i? you don't have to increment before, you can also i++ after, in such cases.. Forget about C here, C is a trash for logic, a pain in the ass

[Martin_fr]

After a for loop the loop variable must not be used without being reinitialized.

Sorry but that is wrong: https://www.freepascal.org/docs-html/ref/refsu58.html

If the loop was terminated prematurely with an exception or a break statement, the loop variable retains the value it had when the loop was exited.

So there a cases where the loop variable can be accessed after the loop.

Using this "feature" in real code is an ugly hack. Yes, ugly hacks are allowed in Pascal too.

I never said anything about this being a good idea or not. I simple stated that the initial statement was wrong. It is wrong. (period).

[mercurhyo]

yes it looked like an ugly hack before i stated 
Now everyone  (re)reading my corrected comments should see the blaise light  on the 'hack'

[ASerge]

Code: Pascal  [Select][+][-]

1. var i:integer;
2. begin
3.   for i := 0 to 9 do  writeln(i);
4.   writeln(i);
5.   for i := 0 to 9 do
6.   begin
7.     writeln(i);
8.     if i = 9 then break;
9.   end;
10.   writeln(i);
11. end.

Run the same in Delphi.... where 9 becomes 10....

Maybe I misunderstood, but Delphi and FPC output 9 at the end.
I found only two differences after the first cycle:
1. The variable i is 10 in Delphi and 9 in FPC. But in both cases it is described that the value is undefined, so it is normal.
2. Delphi warns that the value will be undefined, FPC unfortunately no.

[Thaddy]

Maybe I misunderstood, but Delphi and FPC output 9 at the end.

The point I was trying to make is exactly what you describe: whatever happens do nit rely on the value, although when you use break or exit the variable seems preserved.
In both dialects! - it is also documented for FreePascal - the value is undefined. Except - for some reason - when you break out of the loop. For FPC that is somewhat documented.
I think that part of the documentation should be removed. If you need the value, re-assign to another variable at the point from inside the loop that you want to break out of.
The 9-10 issue demonstrates exactly that.... the "if i = 9 then break;" tries to give an example to test against both Delphi and FPC behavior.
I think - if you agree - we should ask Michael to remove the last part of the quote from the documentation, because the behavior is deterministic (by accident) and not based on the language at all.

BTW the reason that the value is preserved in case of premature exit us that in that case the number of iterations may have value. But IMHO that value should be assigned to another variable on exit.

[totya]

After first cycle, the correct <i> value is 9.

If the loop was terminated prematurely with an exception or a break statement, the loop variable retains the value it had when the loop was exited.

So, if under Delphi the <i> value is 10, then Delphi works badly (but I want to see it).

The value of the loop variable is undefined after a loop has completed

This is mean, after the cycle, u can rewrite <i> value, so this can different from cycle exit value, and nothing more ore less.

[ASerge]

I think - if you agree - we should ask Michael to remove the last part of the quote from the documentation, because the behavior is deterministic (by accident) and not based on the language at all.
BTW the reason that the value is preserved in case of premature exit us that in that case the number of iterations may have value. But IMHO that value should be assigned to another variable on exit.

Which part? I think that the documentation is correct.
I agree that using a variable after a for loop is a bad style. If we need the value of a loop variable, we'd better use a while loop.

After first cycle, the correct <i> value is 9.
So, if under Delphi the <i> value is 10, then Delphi works badly (but I want to see it).

The value of the loop variable is undefined after a loop has completed

This is mean, after the cycle, u can rewrite <i> value, so this can different from cycle exit value, and nothing more ore less.

I think you're just confused. The value is defined only if the cycle is interrupted. If it passed completely, its value is undefined. This is reflected correctly in the documentation. Delphi and FPC behaviors are consistent with the documentation.

[Thaddy]

I think you're just confused. The value is defined only if the cycle is interrupted. If it passed completely, its value is undefined. This is reflected correctly in the documentation. Delphi and FPC behaviors are consistent with the documentation.

Yes, they are.

[totya]

Show me any code, after the cycle finished, the cycle variable isn't equal to cycle exists value. So, mr. confused?

[giahung1997]

OK. Keep watching the thread going but I can't understand much what anyone said. I know Free Pascal will not implement such hybrid chimera like PascalABC.NET, even I now see what must be wrong with PascalABC.NET. I prefer Pascal to be Pascal, not a mixture. I'd like to add the ability to declare variable inside the body of functions/procedures (not only on the section var before begin end;) to be more convenient for testing. Might be via a compiler option ($define sth). Now I write a prototype (working but dirty code) with Fantom first then I port it to Free Pascal later. It's difficult for a non-pro like me to foreknow everything to declare on var section first. Imagine a very long function/procedure, everytime I want to use an additional temp variable I have to jump to the var section and declare it. This feature of C like language is very convenient for testing, experimenting but I prefer the current Free Pascal style for something serious. I reviewed the PascalABC.NET code and I see it has type inference too. I definitely don't need this (despite Fantom has it, since it's a weak and dynamic type language). Pascal code become ugly if it doesn't have types  About the 'var' in for loop, I see it ugly. Even on Fantom, it's just for(i := 1; i <= 10; i++), no var before i, it's meaningless. And I don't want to use the value of i after the loop finished too. If I want to count something, I will add a count := 0 before the loop and count++ inside the loop 

[ASerge]

Show me any code, after the cycle finished, the cycle variable isn't equal to cycle exists value. So, mr. confused?

This is only the specifics of the current implementation, which can change at any time.

Let's take a simple code:

Code: Pascal  [Select][+][-]

1.   for i := iStart to iEnd do
2.     Body(i);

This is FPC implementation (now!)

Code: Pascal  [Select][+][-]

1. i := iStart;
2. if i <= iEnd then
3. begin
4.   Dec(i);
5.   repeat
6.     Inc(i);
7.     Body(i);
8.   until i >= iEnd;
9. end;

As result at end i equal iEnd

This is Delphi implementation (also now, but for many years)

Code: Pascal  [Select][+][-]

1. i := iStart;
2. Dec(iEnd, i);
3. if iEnd >= 0 then
4. begin
5.   Inc(iEnd);
6.   repeat
7.     Body(i);
8.     Inc(i);
9.     Dec(iEnd)
10.   until iEnd = 0;
11. end;

As result at end i equal iEnd+1
By the way, on intel platform code for Dec(iEnd); until iEnd = 0 is fatster, then until i >= iEnd, because read only one register/memory and test result for zero without compare.

Maybe later will be used even faster algorithm, so it is better not to rely on what is now, and believe the documentation.

[Zoran]

Show me any code, after the cycle finished, the cycle variable isn't equal to cycle exists value. So, mr. confused?

The point is that it is undefined. You cannot rely on experiments.
The docs clearly says it is undefined, so you should treat it as unpredictable.

Even if it is actually implemented so currently (which still might not be the case, perhaps sometimes, maybe very rarely, you get different behaviour), this can change in next version without notice.

[ASerge]

...Imagine a very long function/procedure, everytime I want to use an additional temp variable I have to jump to the var section and declare it.

Due to the rigor and clarity of the program is easy to read and understand. If you write a procedure that does not fit on one screen, and even more so offer to scatter in it the definition of variables, even you do not understand after half year, what's what, and even more so the other person.