For variable being read after loop... Any way to get an error or warning on it?

[Joanna]

It might be ok to have uninitialized variables but shouldn’t it give a warning if the value of “i” is truly undefined after the loop? There is nothing wrong with making pascal language more robust is there?

[MarkMLl]

It might be ok to have uninitialized variables but shouldn’t it give a warning if the value of “i” is truly undefined after the loop? There is nothing wrong with making pascal language more robust is there?

You really haven't read the thread, have you?

Telling the compiler to re-mark i as being undefined (as distinct from being undeclared) is precisely what Marco suggested, and it would be far less contentious than my suggestion.

But the bottom line here is that Pascal, as a language, can't be tightened up in this area without specifically going against Wirth's definition, and even if one implementation changed it other's wouldn't hence resulting in the sort of compatibility problem that's bitten OP.

MarkMLl

[marcov]

It might be ok to have uninitialized variables but shouldn’t it give a warning if the value of “i” is truly undefined after the loop? There is nothing wrong with making pascal language more robust is there?

What warnings are emitted is typically not part of a language definition. It would still be a good thing to add it to FPC, which is why there were several calls to submit a detailed bug report for it.

[MarkMLl]

What warnings are emitted is typically not part of a language definition. It would still be a good thing to add it to FPC, which is why there were several calls to submit a detailed bug report for it.

I was going to put something along the lines of the whole concept of warnings (and notes) being outside the language as specified by Wirth (I can't speak for the rather later ISO document).

Wirth defined Pascal in the late 60s, the seminal J&W was pre-1975 (can't find a date for the first edition) and leaned heavily on an earlier ETHZ report. Compilers- certainly on relatively-small systems- only progressed past the point where they halted at the first sign of error or ambiguity and started making value judgements in the mid-80s (Logitech, which at the time was a Swiss company with tenuous links to Wirth's research group was one of the earliest).

MarkMLl

[Joanna]

It might be ok to have uninitialized variables but shouldn’t it give a warning if the value of “i” is truly undefined after the loop? There is nothing wrong with making pascal language more robust is there?

What warnings are emitted is typically not part of a language definition. It would still be a good thing to add it to FPC, which is why there were several calls to submit a detailed bug report for it.

I hope a warning can be made for this sort of thing if it is undefined.
Here is a question though. Suppose “i” had a value assigned to it and then was used in a loop ? What would the value of “i” be then?

[440bx]

Suppose “i” had a value assigned to it and then was used in a loop ? What would the value of “i” be then?

Upon entering the "for" loop, the value of "i" would be set/reset, therefore its value would by definition be undefined when exiting the loop.  Also, it is an error (flagged by the compiler) to attempt setting the loop variable to some value, IOW, the loop variable is not allowed to be an lvalue (value on the left of an assignment.)

[Joanna]

Logically the variable should just stay what it was last assigned to. There is also the circumstance of breaking out of the loop early which I suppose would leave it at the last assigned value.

I don’t know much about compiler development but it would be nice if the setting index could unambiguously assign the value to variable.

[Handoko]

Logically the variable should just stay what it was last assigned to. There is also the circumstance of breaking out of the loop early which I suppose would leave it at the last assigned value.

I don’t know much about compiler development but it would be nice if the setting index could unambiguously assign the value to variable.

I prefer "no".

The most important reason I abandoned BASIC to use Pascal was, binaries generated using Pascal (TP and now FPC) have very efficient code and they run fast. I know nowadays computers run very fast, the performance gain is unnoticeable. But I prefer the slim fast cheetah instead of huge powerful elephant.

There is also the circumstance of breaking out of the loop early which I suppose would leave it at the last assigned value.

When my code breaks the loop, that usually means a desired result already found, Result := i; so the i can be retired.

[Joanna]

Would it really bloat the compiler to keep value of the variable after loop through?

Also if “i” was used inside a while or repeat until loop the values assigned Therein would not be undefined..

I think it’s possible to change the loop variable within the loop but the loop will only iterate to what the original variable was. I experimented with some code someone gave me doing that. It somehow retains the number of possible iterations somewhere..

[MarkMLl]

Here is a question though. Suppose “i” had a value assigned to it and then was used in a loop ? What would the value of “i” be then?

Undefined, as per Wirth. There is no creation of a block-local variable which hides the original.

If you don't like it then don't use Pascal.

MarkMLl

[MarkMLl]

Would it really bloat the compiler to keep value of the variable after loop through?

Joanna, get it into your thick head: THIS IS NOT A COMPILER ISSUE, IT IS A LANGUAGE ISSUE.

Even if FPC in some or all of its modes defined that the value be retained, any other strict-Wirth Pascal compiler would be at liberty to leave it undefined. And anybody using Pascal in a controlled environment- ISO9001 or whatever- would be /obliged/ to assume that the value was indeterminate.

MarkMLl

[Handoko]

Would it really bloat the compiler to keep value of the variable after loop through?

You should learn some Assembly for better understand it. How much it bloat is not very important here. The most important thing is the case you mentioned is very rare. Even if it happens, you can easily set the value to another variable. Let the looping variables be used for looping only, this short advice seems trivial, but this is an important thing a professional programmer should do: write a clean code.

Some of my codes in BASIC depended on the looping variables at the end of For-Next, they worked properly. But if I compare them with my Pascal codes now, they are ugly. Now my codes in Pascal code have variables for looping, variables for calculation, etc. Each of them performs their own task. Nice. No more messing up like my old codes in BASIC.

Also as explained by MarkMLI, this behavior was already set in the past.

I think it’s possible to change the loop variable within the loop ...

Then you should use Repeat-Until or While-Do statements instead.

Also if “i” was used inside a while or repeat until loop the values assigned Therein would not be undefined..

The looping variables in For-Do are optimized for performance, some rules need to be applied. It has been explained in the past. So let looping variables be used for looping only. While-Do and Repeat-Until are not so optimized, as far as I know.

[440bx]

Would it really bloat the compiler to keep value of the variable after loop through?

at first thought, it would likely only take a single additional instruction added when the loop ends to preserve the value of the index variable.

However, doing that causes a BIG problem, which is, if someone ports FPC code that depends on that "feature" (actually, a violation of the Pascal standard) ports the code to another Pascal compiler (say, Delphi), that compiler is rather unlikely to guarantee the value of the loop variable at the end of the loop.

That wouldn't be the only difference with other Pascal compilers but, the BIG problem is that it is not a difference the other compiler may detect.  This would cause extremely hard to find bugs.

There is no good reason to deviate from the standard given that if someone wants to depend on the final value all they have to do is to assign the value of the index variable to a plain variable and, that is fully portable across all standard-compliant Pascal compilers (and likely even those who deviate to some extent.)

[Joanna]

The looping variables in For-Do are optimized for performance, some rules need to be applied. It has been explained in the past. So let looping variables be used for looping only. While-Do and Repeat-Until are not so optimized, as far as I know.

It makes sense that a dedicated loop variable.
@440bx
It’s a shame that compatibility with other versions of pascal is holding back better design.

[440bx]

@440bx
It’s a shame that compatibility with other versions of pascal is holding back better design.

The "for" loop is designed for maximum performance that's why the standard states that the index variable is undefined upon the loop ending normally (allows for the index to be in a CPU register.)

Anyone who wants to rely on the index value once the loop has ended has multiple options: 1. assign the index to a variable inside the loop, 2. use a "while" or "repeat" loop instead of a "for" loop, 3. other options (such as making a loop using gotos and labels and/or who knows what else.)

The Pascal "for" loop is designed for performance and it fulfills that purpose very well.