Ada style "for" loop counters

[AlanTheBeast]

Sooner or later someone will ask here, if we could make Pascal become "cAseSenSensiTIVE".   

Please ask it and I'll simply say that would invalidate billions of lines of code.  Thanks, cheers and goodbye.

[Martin_fr]

2) "reserving" the identifier.

Short answer: no big deal - the error will be at compile time.

But still better if I never got the error in first.

Code: Pascal  [Select]

1.   for a := 0 to 9 do write(a);
2.   for a := false to true do write(a);

confusing, since "a" in the same procedure is at some time int, and then bool.

Confusion is in the eye of the beholder.  To be sure an Ada programmer is used to this notion and would not worry about it.

"an Ada programmer is used", but what about pascal programmers?
fpc is pascal, not  Ada.

4)

Code: Pascal  [Select]

1. for NameOfAGlobalVar :=

Hides a global var.

That's very true. OTOH, the usual variable names for such are quite short (i, j, k, m, n, p, q) and usually used over a short number of lines of code.

Further, the use of simple loop control variables in a procedure should (generally) not use globally declared variable names; in turn global variable names should (generally) not be simple and undescriptive as simple loop variables typically (i,j, ..) are.  Yes, that 's style to an extent.

"should"  But there is no warranty. So the problem will exist.

To be fair: Every feature brings good and bad. The only question is, if the good outweighs the bad. Saving one line in the declaration to me does not any good, so it does not outweigh the problems.

If you are worried about reading the one line in declaration, use code folding.

You could provide a patch to hide (entirely fold, no visible line left) "{$region}". And have it fold/hide on load. Then put anything you dislike seeing into such region.

5) There is no optional.

Bwahahahahaahahahahahahah!!!!! 

Really? Laughter? Does that means you agree, and you are a good loser, taking it with laughter?

This time I added a smiley myself, this time you may laugh.

[AlanTheBeast]

"an Ada programmer is used", but what about pascal programmers?
fpc is pascal, not  Ada.

I've made the point that Ada contains a lot of Pascal in its DNA.  But the Ada designers saw declaring indexes as a waste of time in most cases.  They did not make it "illegal" for those cases where readability desires it. 

It is something one adopts and loves pretty quick and will actually not harm Pascal programmers at all.

4)

Code: Pascal  [Select]

1. for NameOfAGlobalVar :=

Hides a global var.

That's very true. OTOH, the usual variable names for such are quite short (i, j, k, m, n, p, q) and usually used over a short number of lines of code.

Further, the use of simple loop control variables in a procedure should (generally) not use globally declared variable names; in turn global variable names should (generally) not be simple and undescriptive as simple loop variables typically (i,j, ..) are.  Yes, that 's style to an extent.

"should"  But there is no warranty. So the problem will exist.
[/quote]

And on that day the programmer will have a compile time bug and regret (with good reason) all those simple single letter global variables that he knew he should not have declared (Ahem, I have a lot of units that are thus littered so it's not like I would be able to use this at large in some of those units.  OTOH, this change would not affect the ability to compile those units at all - only if I made such changes.  Thankfully I tend to writing units that are small.

To be fair: Every feature brings good and bad. The only question is, if the good outweighs the bad. Saving one line in the declaration to me does not any good, so it does not outweigh the problems.

If you are worried about reading the one line in declaration, use code folding.

You could provide a patch to hide (entirely fold, no visible line left) "{$region}". And have it fold/hide on load. Then put anything you dislike seeing into such region.

It's not about hiding existing declarations.   The notion of these undeclared but properly typed indexes is simplicity in programming, reading and in maintaining code over the long haul.

5) There is no optional.

Bwahahahahaahahahahahahah!!!!! 
[/quote]
Really? Laughter? Does that means you agree, and you are a good loser, taking it with laughter?

This time I added a smiley myself, this time you may laugh.
[/quote]

Call it a well deserved grin.

Loser? Not at all.  I believe strongly that this is a "good thing" to add to Pascal just as the Ada designers saw that it was a good thing to do despite their otherwise heavy formalism.

Mr. Wirth started a language based on strong declarations for good reason - not the least the lack of sophistication in compilers - it was probably easier to be very strict than it would have been to have some automatic features.

[Martin_fr]

well agree to disagree.

You (appear) to believe, that optional exists for such a feature.

I disagree. Based on my experience, optional does not exist (yes I am serious, no laughter this time please).


If (for argument sake) optional does not exist, then the above will cause harm (to some people).

This is not about how you would use it, you would not be the only one using it.

-------------
Besides what are the benefits?

- less typing (IIRC that was dismissed / should be taken care of, by codetool)
- less code to read (apparently not, since hiding/folding is dismissed as solution

That leaves automatically follow the type of the bounds if they change.

Using a smaller (word instead of int) type for optimization? I am not sure that really will optimize a lot (maybe on embedded), well and 2 bytes on the stack, if it is not in a register.
Besides, a variable that is declared as int, can be optimized the same way, if the compiler can detect that it never holds values that do not fit into word (and is not accessed via pointer or similar)
In any case the rules for the optimization are the same in both cases.

So what are the benefits then?
Maybe that the loop originally written for integer, can still compile if the bounds change to some enum? How likely is that? Both bounds would need to change in the same way. And if they do, any operation  (compare, add, use as index,...) on the loop var, done in the loop must be supported on the new type. IMHO rather unlikely.

What did I miss, what is the benefit?


--------------
the "looser" comment was clearly marked as a joke. I never indented to make any statement with this.

[marcov]

Optimization is a non argument. If the loopcounter is immutable, then the compiler can register it and determine its own bounderies. That has nothing to do with syntax.

[AlanTheBeast]

well agree to disagree.

You (appear) to believe, that optional exists for such a feature.

I disagree. Based on my experience, optional does not exist (yes I am serious, no laughter this time please).

At this point I don't even know what you're on about.   You seem to be throwing objections for that sake alone.

If (for argument sake) optional does not exist, then the above will cause harm (to some people).

This is not about how you would use it, you would not be the only one using it.

To be sure.  But then, since it is a simple and clear enough thing, I don't think that a serious look at how it would be implemented would really find all that much issue.  I mean really, if a compiler can determine a simple type for the index that is no different than how a programmer would declare it, then there isn't much issue.  That is how it's done in Ada.  And where the compiler can't digest it, then a warning/fail is issued.

Besides what are the benefits?

- less typing (IIRC that was dismissed / should be taken care of, by codetool)

a- you might dismiss it, I don't
b- codetool inserting the VAR is not implementing the feature.

- less code to read (apparently not, since hiding/folding is dismissed as solution

Not so much that it is "less code to read" as it is "less clutter in the VAR list".

That leaves automatically follow the type of the bounds if they change.

Using a smaller (word instead of int) type for optimization? I am not sure that really will optimize a lot (maybe on embedded), well and 2 bytes on the stack, if it is not in a register.
Besides, a variable that is declared as int, can be optimized the same way, if the compiler can detect that it never holds values that do not fit into word (and is not accessed via pointer or similar)
In any case the rules for the optimization are the same in both cases.

So, no real issue given sober constraints.  If the range is variable, then the variable define the range.  In the unlikely case that the the bounds are pointer accessed, they are stil type constrained.  If the bounds are overloaded, then simply throw a failure and explain why.

So what are the benefits then?
Maybe that the loop originally written for integer, can still compile if the bounds change to some enum? How likely is that? Both bounds would need to change in the same way. And if they do, any operation  (compare, add, use as index,...) on the loop var, done in the loop must be supported on the new type. IMHO rather unlikely.

What did I miss, what is the benefit?

You didn't miss making the simple into complex, that is for sure.

--------------
the "looser" comment was clearly marked as a joke. I never indented to make any statement with this.

I didn't take it any other way.

[Martin_fr]

At this point I don't even know what you're on about.   You seem to be throwing objections for that sake alone.

Not at all, or not intentional.
I am not sure, if the comments left by some of the members of the fpc team, indicate that the idea is already rejected. If so, then the argument is indeed moot. Otherwise, I do have a point.

Non sure which part you are not sure about. So below may contain some repeats. Sorry.

First about "optional". And that really is the all defining point. (Despite your initial laughter on this)

*IF* this could be truly optional, then it would never affect me (or anyone who has my view on it). If it would never affect me, then I had no other arguments. (Same as, I am not using language X, so I do not care what people do to it)

But it will (as in: there is a possibility) affect me. My boss may ask me to use a 3rd party lib, that uses it, and I may have to read the code.

So my reason is: I argue about it, because it can affect me.

This is not about how you would use it, you would not be the only one using it.

at how it would be implemented would really find all that much issue.

This is not about implementation. I am not maintaining the compiler, so that does not matter do me. And I wouldn't ever notice, if fpc would change a few millisec in speed (faster/slower), or fpc.exe grew a bit in size. None of that is my problem.

You said, you would use it "reasonable", e.g. only short var names to minimize (IMHO still not avoid) conflict with identifiers in other scopes. But other people will (not "may", definetely "will") use it more aggressive. (And I (or others like me) may/will in future be forced to read there code).

- less typing (IIRC that was dismissed / should be taken care of, by codetool)

a- you might dismiss it, I don't

Ok.This is personal preference. So it cant be argued.
But IIRC on the link to the fpc wiki, it is mentioned that this is not accepted as reason for a feature. (I didnt write that wiki)

- less code to read (apparently not, since hiding/folding is dismissed as solution

Not so much that it is "less code to read" as it is "less clutter in the VAR list"

And as I said, to me personally, this decreases readability of the overall code. (And I am probably not alone on this) So this argument goes both ways.

Beside, if codetools would (for loop vars) insert:

Code: Pascal  [Select]

1. {$region 'loop vars' /hide}
2. var
3.   i: integer;
4. {$endregion}
5.  

The editor can be patched to entirely hide (like comment) this. So the "clutter" would never be visible. (Yet I could disable region hiding in my options, so it would not affect me).

That leaves automatically follow the type of the bounds if they change.

Using a smaller (word instead of int) type for optimization? ...
In any case the rules for the optimization are the same in both cases.

So, no real issue given sober constraints.  If the range is variable, then the variable define the range.  ...

I dont understand. You still havent explained what the benefit is (well: less typing, is now on).

- optimization is not, because it can be done, even if the type is declared.
- following the type of the bounds. That could be seen as benefit, but it is extremely rare (as both bounds need to change), and it can also be a danger, as unintended changes to the bound will silently keep compiling. So this evens out (In my book the danger even weighs more than the "benefit")

There is one other point: Having a smaller scope var the loop var. Such scopes where proposed before and rejected. And to me they decrease readability, because they also introduce extra work to find all variables/properties/members/identifiers that are visible to a procedure. (See my comment on "with is bad, because it does something similar).

You didn't miss making the simple into complex, that is for sure.

Sorry, I did not MAKE it complex. I merely pointed out how complex this is (and always was).

Conclusion. In my attempt to learn the benefits:

- I accept that less typing matters to you (But it is not (enough of a) reason to me).

- You find the presence of the loop var in the var section "clutter" (less readable?). To me there absence decreases readability. (I explained that in detail, in previous post)

Both of those are personal preferences. Except the latter (absence) is a fundamental change to the definition of pascal, and would void one of the reasons why I like pascal. So it would be a severe loss.

For all other things, that I could imagine someone might see as benefit, I have explained why they are not.

- optimization of generated machine code: possible in exactly the same way, even if var is declared

- changing type, if boundary changes: can go wrong as easily as it might be helpful / in any case: it is rare to ever happen at all

- micro-scoped var declaration: see argument on "absence in var block"

[BeniBela]

I dont understand. You still havent explained what the benefit is (well: less typing, is now on).

There are a lot of small benefits (like those you listed). They add up

Code: Pascal  [Select]

1. {$region 'loop vars' /hide}
2. var
3.   i: integer;
4. {$endregion}
5.  

You still see that, when you commit the files.

And now you have 4 lines for what used to be one. This is way worse.




Also CodeTools do not remove the declaration, when you remove the loop. Then you have to search through the entire file to remove old loop vars to fix pointless hints

[Martin_fr]

There are a lot of small benefits (like those you listed). They add up

Thats "less typing" / "less reading" (clutter) only. (and from below: less clean up).

And the 2nd (less reading) is (to others) a severe disadvantage/damage.

We obviously weigh those different. But imho, you need much much stronger (and more) reasons, if you want to change one of the fundamentals of pascal (i.e. the need to declare ALL vars in advance).

You still see that, when you commit the files.
And now you have 4 lines for what used to be one. This is way worse.

you can put it all on one line. then that line is also easy to ignore during commits.

But yes, they are still in there. That is the point. Removing them severely damages readability of the code. (well not to you, not to ADA programmers, but to some others / and those others are people who had chosen Pascal, and not ADA)

Also CodeTools do not remove the declaration, when you remove the loop. Then you have to search through the entire file to remove old loop vars to fix pointless hints

1) A clean up of this kind could be added (delete selection and clean variables)
2) That applies to any other code removal too.

Solving this via (1) would be much more universal, as it would help in all cases, rather than a tiny subset only.

[garlar27]

IMHO it is too much work on the compiler side (and it could be much more than we can imagine since it breaks pascal's definition) for some benefits for which not everybody agree.

[bylaardt]

@ AlanTheBest

Code: Pascal  [Select]

1. procedure Test;
2.   procedure ShowA;
3.   begin
4.     writeln(a);
5.   end;
6. begin
7.   for a:=0 to 10 do
8.     ShowA;
9. end;
10.  

Is this a valid code?
because my scope concept says "Are you kiding me?"

[BeniBela]

Code: Pascal  [Select]

1. procedure Test;
2.   procedure ShowA;
3.   begin
4.     writeln(a);
5.   end;
6. begin
7.   for a:=0 to 10 do
8.     ShowA;
9. end;
10. �

Is this a valid code?

Of course not !

The a should only be visible inside the for statement. The procedure is not inside the for statement.

However, this should be valid code:

Code: Pascal  [Select]

1. procedure Test;
2. begin
3.   for a:=0 to 10 do begin
4.     procedure ShowA;
5.     begin
6.       writeln(a);
7.     end;
8.     ShowA;
9.   end;
10. end;
11.  

And I am not kidding

[BeniBela]

And of course this should not be valid either:

Code: Pascal  [Select]

1. procedure Test;
2. begin
3.   for a:=0 to 10 do begin
4.     procedure ShowA;
5.     begin
6.       writeln(a);
7.     end;
8.   end;
9.   ShowA;
10. end;
11.  

but this one again would:

Code: Pascal  [Select]

1. procedure Test;
2. var p: TProcedure;
3. begin
4.   for a:=0 to 10 do begin
5.     p := ( procedure ShowA;
6.     begin
7.       writeln(a);
8.     end)
9.   end;
10.   p();
11. end;
12.  

and print 10 and nothing else

while this should print 0 to 10 :

Code: Pascal  [Select]

1. procedure Test;
2. var p: array[0..10] of TProcedure;
3. begin
4.   for a:=0 to 10 do begin
5.     p[a] := ( procedure ShowA;
6.     begin
7.       writeln(a);
8.     end)
9.   end;
10.   for q in p do q();
11. end;
12.  

Is this not awesome?

[garlar27]

And of course this should not be valid either:

Code: Pascal  [Select]

1. procedure Test;
2. begin
3.   for a:=0 to 10 do begin
4.     procedure ShowA;
5.     begin
6.       writeln(a);
7.     end;
8.   end;
9.   ShowA;
10. end;
11.  

but this one again would:

Code: Pascal  [Select]

1. procedure Test;
2. var p: TProcedure;
3. begin
4.   for a:=0 to 10 do begin
5.     p := ( procedure ShowA;
6.     begin
7.       writeln(a);
8.     end)
9.   end;
10.   p();
11. end;
12.  

and print 10 and nothing else

while this should print 0 to 10 :

Code: Pascal  [Select]

1. procedure Test;
2. var p: array[0..10] of TProcedure;
3. begin
4.   for a:=0 to 10 do begin
5.     p[a] := ( procedure ShowA;
6.     begin
7.       writeln(a);
8.     end)
9.   end;
10.   for q in p do q();
11. end;
12.  

Is this not awesome?

NO, I DON'T THINK SO.

I never could see the "good part" of those "disposable"  function/procedure. Is bloody awfull to mantain 

[bylaardt]

procedure "ShowA" is in the same scope as the "a" was declared and i can't access "a"?

This is a distortion of scope concept, sorry if just me who think so, but IMHO this is unacceptable.
if anyone implement this, rename the language to another name, because this is not Pascal, and not Ada too, maybe another dialect, like "lazy's pascal"