Question ?!!!!

[dbannon]

... The undefined variable problem seems trivial to fix and didn’t seem undefined at all when I tested it.

Sigh, you have missed the point entirely Joanna. The fact is that on particular hardware and particular optimization levels, the "undefined" variable does often have the expected value. Thats why its so dangerous, it can slip past your testing, working perfectly. But, someone then builds your code on, say,  powerel64 or maybe an arm32 system and it crashes badly, they tell you, you test again, you tell them they are wrong. They decide your software is unusable.

Davo

[Joanna]

Well if that’s the case there should definitely be a warning about using an undefined  variable if it’s used after loop or before anything is assigned to it. How difficult would it be to make that a warning?

[MarkMLl]

Well if that’s the case there should definitely be a warning about using an undefined  variable if it’s used after loop or before anything is assigned to it. How difficult would it be to make that a warning?

As discussed in the other thread, I raised a big report as suggested by Sven who pointed out that raising a warning (i.e. similar to other unininitialised variable warnings) is non-trivial: at least if it is not to be swamped by false positives.

Unfortunately this is something which is in Pascal (as a language, rather than as a specific implementation), and I believe it came about because of the difficulty Wirth had in massaging his ALGOL-W compiler into one for a new language. This predates the "P" series of recursive descent compilers, and most of the changes that he made relate to the syntax and semantics of declarations rather than to code syntax i.e. statements and expressions.

I suppose that an alternative would be to define that in ObjFPC mode the variable /could/ be relied on, but that would potentially incur the wrath of anybody still concerned with portability of the language. With all respect Joanna, but Pascal- as a language- is far wider than just FPC/Lazarus/Delphi, and one can only get away with things like "this is easy to fix" if one insists that there is only a single worthwhile implementation (i.e. the one you're using) and all others are heretical.

I wonder what the position of Ada (and Modula-2 etc.) is on this one?

MarkMLl

[MarkMLl]

Delphi is probably headed towards destruction if it’s trying to imitate scripting languages. The undefined variable problem seems trivial to fix and didn’t seem undefined at all when I tested it.

Out of curiosity, what do you mean by "scripting language" in this context?

I'm not asking for examples, of (what you consider to be) scripting languages, but am trying to get to the bottom of what concepts you consder define them and why you consider that Delphi is trying to follow suit.

MarkMLl

[Joanna]

Delphi is probably headed towards destruction if it’s trying to imitate scripting languages. The undefined variable problem seems trivial to fix and didn’t seem undefined at all when I tested it.

Out of curiosity, what do you mean by "scripting language" in this context?

I'm not asking for examples, of (what you consider to be) scripting languages, but am trying to get to the bottom of what concepts you consder define them and why you consider that Delphi is trying to follow suit.
MarkMLl

I believe it was alpine ?  who mentioned that scripting languages are more flexible with variable declaration. My experience with a scripting language concurs.

I understand that the original version of pascal by wirth was not perfect  didn’t enforce what to do with loop variable after the loop. Maybe there are other versions of pascal out there that don’t address the undefined variable after loop issue.

At this point fpc will probably out live Delphi if Delphi is resorting to this sort of convoluted nonsense.

Why be stay tethered  to inferior versions of pascal?
If the variable is indeed Not guaranteed to be what it was last assigned in the loop {or is uninitialized } something should be done about using undefined variables.
Allowing this is not robust language design. If people are porting old pascal code to fpc and are trying to use an unassigned variable. It should warn them in my opinion or even give a compile error. I don’t know much about compilers so I don’t know how this can be done but it definitely should be done...

[MarkMLl]

OK. Please understand that I'm not trying to criticise or snipe here, just trying to get to the bottom of things.

I believe it was alpine ?  who mentioned that scripting languages are more flexible with variable declaration. My experience with a scripting language concurs.

Maybe, but I think you've been making the distinction for some while. I think that the point he might have been making was that that type of language tends to be far more heavily oriented towards global variables possibly modified by a namespace prefix, although I'd tentatively suggest that at least some of them belatedly adopted the ALGOL/Pascal scoping rules (to the extent that they could without breaking their backwards compatibility).

Scripting languages, and others with a "compile on demand" or "execute this string" facility, also tended to allow things to be declared and undeclared on the fly. Note that I'm saying "declared" here, i.e. something exists as a named entity, rather than "defined" i.e.something has a sensible value (in many cases this is non-nil, consider Pascal's Assigned() function).

So if we have broad agreement over what a scripting language is (and I don't think we're far from that), then it is possible to "undeclare" something by expunging this from the relevant namespace: and this is distinct from allocating something the undefined value (nil or whatever).

I'd throw in that some languages are more serious about the behaviour of undefined values than others. For example, in SQL the result of a nil = nil comparison is false, since no assumptions at all can be made about that content.

In ALGOL/Pascal it's not possible to undeclare something, although it's possible to (unintentionally) lose a reference to something on the heap resulting in a dangling pointer. The nearest you can get is a pointer with a nil value, but that pointer is still normally identified by name so it's not really undeclared. However when doing very low-level work one can hit problems, since while a pointer containing a nil cannot he dereferenced a pointer containing a zero address can... but their bit patterns are indistinguishable.

So there is really no bit pattern which can be assigned to a pointer to call it undefined. Similarly, there is no bit pattern that can be assigned to an integer which will be unambiguously interpreted as undefined: that's why a (16-bit, signed) integer runs -32768..+32767 with no gaps.

So in ALGOL/Pascal and their derivatives, there is no way to undeclare something (declaration is handled by the scoping rules), and no value that can be assigned to a pointer or integer which will be unambiguously interpreted as undefined.

I understand that the original version of pascal by wirth was not perfect  didn’t enforce what to do with loop variable after the loop. Maybe there are other versions of pascal out there that don’t address the undefined variable after loop issue.

Are you seriously suggesting that there are versions of Pascal that weren't invented by Wirth?

At this point fpc will probably out live Delphi if Delphi is resorting to this sort of convoluted nonsense.

Why be stay tethered  to inferior versions of pascal?

For compatibility with what Wirth defined.

If the variable is indeed Not guaranteed to be what it was last assigned in the loop {or is uninitialized } something should be done about using undefined variables.
Allowing this is not robust language design. If people are porting old pascal code to fpc and are trying to use an unassigned variable. It should warn them in my opinion or even give a compile error. I don’t know much about compilers so I don’t know how this can be done but it definitely should be done...

Sven said that it was something best considered by Florian. Knowing the extent to which Sven's been deeply involved with the compiler I wouldn't for one minute dream of arguing about that.

MarkMLl

[Joanna]

Quote
At this point fpc will probably out live Delphi if Delphi is resorting to this sort of convoluted nonsense.

Why be stay tethered  to inferior versions of pascal?

For compatibility with what Wirth defined.

But we have already diverged from delphi because we don’t allow variable declarations all over the place. So staying compatible with every other version of pascal has already Been given up on. 

[440bx]

I don’t know much about compilers so I don’t know how this can be done but it definitely should be done...

It should be done if, and likely only if, the warning message applies to the situation.

It is very common to see code that re-uses an index variable, commonly named "i", for multiple purposes which doesn't mean "i" is being used when it has  an undefined value, therefore in those instances a warning is just noise that gets in the way of giving attention to other warnings that may be helpful.

As it is, FPC already has a tendency to emit a lot of messages (in the form of hints and warnings) that are of very little use (and quite commonly totally useless) which makes paying attention to really important messages more difficult (because one has to visually parse the junk out.)

The reason behind wanting a warning in that situation is reasonable but, it isn't simple for the compiler to determine if the warning is applicable or not.  In the case of the "for" loop, there is no way for the compiler to determine, in all cases,  at compile time if a warning is warranted or not.  There is no clairvoyant algorithm that can determine at compile time if a "for" will end normally or because of a conditional "break" instruction that may be present in the loop.

Maybe a practical solution is to emit _one_ (and only one) generic warning about the control variable whenever the compiler sees a program that uses a "for" loop (which is probably around 90%+ of Pascal program), that way, those who don't read documentation and/or are new to Pascal get clued into the fact that the control variable's value isn't guaranteed to be valid in all cases.  The compile time cost of that implementation is negligible and doesn't violate standard Pascal rules.

[alpine]

I believe it was alpine ?  who mentioned that scripting languages are more flexible with variable declaration.

Did I?

Last but not the least comes the type inference. I'm not thrilled and I don't think it's an advantage, even if it is presented as such. Rather it is a veer towards scripting languages

Note the words "type inference": https://blogs.embarcadero.com/introducing-inline-variables-in-the-delphi-language/#Type_Inference_for_Inline_Variables

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

1. procedure Test;
2. begin
3.   var I := 22;
4.   ShowMessage (I.ToString);
5. end;

That's what I've meant - it can be declared anywhere and without an explicit type name.

I don’t know much about compilers so I don’t know how this can be done but it definitely should be done...

It should be done if, and likely only if, the warning message applies to the situation.

It is very common to see code that re-uses an index variable, commonly named "i", for multiple purposes which doesn't mean "i" is being used when it has  an undefined value, therefore in those instances a warning is just noise that gets in the way of giving attention to other warnings that may be helpful.

+1

[cdbc]

Hi
@440bx:

Maybe a practical solution is to emit _one_ (and only one) generic warning about the control variable whenever the compiler sees a program that uses a "for" loop (which is probably around 90%+ of Pascal program), that way, those who don't read documentation and/or are new to Pascal get clued into the fact that the control variable's value isn't guaranteed to be valid in all cases.  The compile time cost of that implementation is negligible and doesn't violate standard Pascal rules.

That's a HUGE +1 from me.
Personally, I've been using pascal since the early 80's (TP3) and I've *never* relied on the 'for-loop-counter' after the loop! I was told early on, "It's undefined, don't rely on its value, after the loop", so I've never had failure on that account...
<cynical>
To be honest, Pascal has been doing fine for ~ 50 years, so *why* suddenly this *nonsense* about the for-loop?!? Just tell the newbies: "Don't rely on the 'for-loop-variable' after the loop, without reinitialization or break!" and be done with it... </cynical>
Just my 2 cents
Regards Benny

[silvercoder70]

It has probably become a thing now because languages such as javascript, ruby and python the programmer can "use" (print?) he value after the loop has ended.

As such, if you move to "pascal" from these languages you might think the variable is useable. This line of thought would not have occurred about 15 year ago?

Combine that a lot of self-taught programmers ... and whether they look at documentation is another question. Not picking on these programmers as those who have studied can make the same mistake.

[MarkMLl]

Note the words "type inference": https://blogs.embarcadero.com/introducing-inline-variables-in-the-delphi-language/#Type_Inference_for_Inline_Variables

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

1. procedure Test;
2. begin
3.   var I := 22;
4.   ShowMessage (I.ToString);
5. end;

That's what I've meant - it can be declared anywhere and without an explicit type name.

That is, quite bluntly, Not Pascal.

In fact I'm pretty sure that it's no language in which Wirth had any part, i.e. it's Not Ada, Not Modula-2 and so on.

It /could/ be argued that if the scope of i was limited to the immediately-following statement that as an inline declaration... but no, the absence of a type which determines the size of the variable and its signedness is immediately problematic.

I stick to my earlier position: there's an argument for an inline declaration in the context of for...do or with...do, but anything else stretches the language beyond breaking point.

In addition, from the POV of somebody who does profess to know a bit about the innards of a compiler: while in the general case progressive inline declaration of variables doesn't worry my too badly, once one starts considering it in combination with the implicit try...finally implied by reference-counted variables (non-shortstrings, dynamic arrays etc.) things get hairy. And hairy code structure implies complex edge-cases and potential bugs: and the last place you want bugs is in a code generator and the structure of the sequences that it is emitting.

MarkMLl

[PascalDragon]

FPC sort of implements something like that using inline functions/procedure but, it's far from what it should be because the inline function/procedure has its own stack frame instead of using the stack frame of the function/procedure that encloses it.

Considering that this is not the intended purpose of anonymous functions, they are implemented as they should be.

What could be done however is to correctly implement inlining for anonymous functions called directly. Then you'd have what you wanted... (it currently mainly hinges on the order functions are processed, so it can be made possible)

I suppose that an alternative would be to define that in ObjFPC mode the variable /could/ be relied on, but that would potentially incur the wrath of anybody still concerned with portability of the language.

It would also mean that the compiler can't optimize the for-loop as well.

Why be stay tethered  to inferior versions of pascal?
If the variable is indeed Not guaranteed to be what it was last assigned in the loop {or is uninitialized } something should be done about using undefined variables.
Allowing this is not robust language design. If people are porting old pascal code to fpc and are trying to use an unassigned variable. It should warn them in my opinion or even give a compile error. I don’t know much about compilers so I don’t know how this can be done but it definitely should be done...

If you would have read the posts mentioned by MarkMLI you'd know that he already opened a bug report to have such a warning. So we agree that it should be done. Now it's only a matter of when.

[MarkMLl]

If you would have read the posts mentioned by MarkMLI you'd know that he already opened a bug report to have such a warning. So we agree that it should be done. Now it's only a matter of when.

I presume that your previous mention of DFA is Data Flow Analysis, which from my POV is Very Deep Magic Indeed.

Joannna, I know that you neither like nor trust Wikipedia, but before posting any more "should be done" or similar sentiments I suggest that you read at least the first part of https://en.wikipedia.org/wiki/Data_Flow_Analysis

MarkMLl

[Raid]

I see a lot of "it's not Pascal". Who determines if it's "Pascal"? A group of individuals? We did not invent Pascal, so how can you say something is not "Pascal"? The inventor of Turbo Pascal went on to C# which is rapidly adding things like type inference, inline variables, and many more welcome additions. If you want to keep to the actual 'spirit of the inventor', then why aren't you following suit?

You ask: submit a patch and they may accept it. I had submitted a HEREDOC Patch (multiline string) that the community wanted YEARS ago (I was on this forum since 2005), but it got rejected. I even followed the comments for it. Why would I want to keep adding to the compiler if the patches won't get included?

Who then, is this "Free Pascal" for? A small group of people? If so, why? You say: "We cater to the Pascal community, not Delphi" .. Then what has Free Pascal doing till now? Is Delphi not "Pascal"? They are the ones who own Pascal. They're the original, they're the ones who pioneered it and added inline variables and type inference, etc. Free Pascal has always been the "Free Competitor". The one we could go to and still use Delphi packages and be fully cross platform.

Pascal should be for everyone. You have to think: What all came from Delphi? Type Helpers? Advanced Records? Generics? Are these not "Pascal"? Did you guys invent them? Free Pascal could've been an amazing alternative, still can be, but some core members need to change their mindset and start adding things that people are getting from other languages (and from Delphi itself), and go back to the original cause. Because you have to ask yourself, why is it named "Free Pascal"? Is it not meant to be the "Free Alternative"? We must go back to the roots.

Edit: Distinction between inventor of Turbo Pascal vs language. No disrespect to Niklaus Wirth (the inventor of the language).