FPC Feature request/suggestion

[eljo]

... no internet to refresh it I might have installed my self too.

No internet ?... how did you manage to get this post in the forum without internet ?

If you care to quote the complete sentence

Now If I could refresh the license when I felled like it and avoid the unpleasant situation where I end up with an expired license and no internet to refresh it I might have installed my self too.

you will get your answer, apparently that is not the situation today, and no, internet connection is not guarantied while coding, in fact I find it distracting so I turn it of most of the times, and that is the main reason of "no proper offline help / documentation never gone in my development machine" rule.

[winni]

Dixie cups and string!

Have not used it for decades.
Hope they made some progress!

[ASerge]

Now, let's add a compound statement to that "for" loop and declare a new inline variable, like this:

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

1. procedure ForTest;
2. begin
3.   var total    := 0;
4.   var mischief := 0;
5.  
6.   for var I: Integer := 1 to 10 do
7.   begin  // starts a new scope
8.     var I : integer := 3;  // does this override the index variable or does the compiler add it automatically (and silently) to the new begin/end scope ?
9.  
10.     Inc (Total, I);
11.     mischief := I * total;   // which "I" gets used ?, the index or the one in the begin/end scope ?
12.   end;
13. end;
14.  

Too bad I don't have a copy of Rio to see how the compiler handles that one.  I guess it probably adds the index variable automatically into the compound statement scope, thereby causing a duplicate identifier error.

Yes. E2004 Identifier redeclared: 'I'

By the way, I remembered one of the commandments of c++ (java): Do not declare more than one variable per declaration. Bad code

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

1. int i, j = 1;

[munair]

Now, let's add a compound statement to that "for" loop and declare a new inline variable, like this:

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

1. procedure ForTest;
2.   // ...
3.   for var I: Integer := 1 to 10 do
4.   // ...
5.  

Too bad I don't have a copy of Rio to see how the compiler handles that one.  I guess it probably adds the index variable automatically into the compound statement scope, thereby causing a duplicate identifier error.

Yes. E2004 Identifier redeclared: 'I'

By the way, I remembered one of the commandments of c++ (java): Do not declare more than one variable per declaration. Bad code

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

1. int i, j = 1;

A 'var' statement as the start of a for loop is a kind of cluttering a compiler should not encourage/allow IMO. It is a 'feature' which usefulness (if at all) cannot compare to the declaration of multiple variables per statement.

[piola]

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

1. ...
2.   for var I: Integer := 1 to 10 do
3.   begin  // starts a new scope
4.     var I : integer := 3;  // does this override the index variable or does the compiler add it automatically (and silently) to the new begin/end scope ?

That should give an "identifier redeclared" error.

[440bx]

By the way, I remembered one of the commandments of c++ (java): Do not declare more than one variable per declaration. Bad code

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

1. int i, j = 1;

Is there a justification for that commandment or is it simply ordained by divine powers that appeared next to a burning hard drive ?

[PascalDragon]

Plus it is not important to me. Unlike the intrinsic you implemented some time ago, which I would really use a lot, but it was finally rejected.

My current idea is that it will make a comeback as an if … then … else expression (which I had implemented as a proof of concept before that already as well).

Now for those who want the feature, the next question after this

You can think of my argument as weak as you want, I'll not implement this.

should be, if he would object to it being added to the compiler, if any other member of the fpc core team would implement it (or apply a well written patch).

Every person in the project can
- decide what they are willing to add themself (as long as not objected by the team)
- ask the team to consider objection / or let things happen

If there is another team member that implements this or commits a patch or if the majority of the team decides that we want this, then I won't object.

Today I implemented immediate constants in the SharpBASIC compiler, which reminded me of this feature request that appears not easy to implement because of FPC's code reuse involving constants.

I suspect the idea is the same: collect immediates, register them as constants (preferably without duplicates) and replace all immediates with constants.

[SNIP]

The difficulty with FPC is probably that this feature wasn't on the table for a long time while at this point it may require too much refactoring to get it done.

Sometimes I have the feeling that I'm talking to a wall... For local variables it's technically absolutely no problem to implement this! It's removing a check and adding a loop and presto, you're done! (global variables would be another topic) Here. For those that want to play around with it I've attached a patch. I won't commit this however (aside the fact that it would also need to be added for global variables for consistency).

[MarkMLl]

Plus it is not important to me. Unlike the intrinsic you implemented some time ago, which I would really use a lot, but it was finally rejected.

My current idea is that it will make a comeback as an if … then … else expression (which I had implemented as a proof of concept before that already as well).

I like the idea of an inline if-then-else, not because it's in C etc. but because it was considered sufficiently fundamental that it was in ALGOL-60... "A better langauge than most of its successors" as I think it was Hoare who said.

MarkMLl

[MarkMLl]

Now, let's add a compound statement to that "for" loop and declare a new inline variable, like this:

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

1. procedure ForTest;
2. begin
3.   var total    := 0;
4.   var mischief := 0;
5.  
6.   for var I: Integer := 1 to 10 do
7.   begin  // starts a new scope
8.     var I : integer := 3;  // does this override the index variable or does the compiler add it automatically (and silently) to the new begin/end scope ?
9.  
10.     Inc (Total, I);
11.     mischief := I * total;   // which "I" gets used ?, the index or the one in the begin/end scope ?
12.   end;
13. end;
14.  

A for-do statement doesn't have to make use of its index variable inside the block being controlled, hence there's no requirement that the index variable be visible. Therefore ISTM that the correct behaviour would be for the newly-declared i to be distinct from the index variable: it doesn't take the same value, and changing it doesn't (of course) affect the iteration.

More interesting is

Code: [Select]

  for var i: Integer := 1 to 10 do
  begin  // starts a new scope
    var j: integer := i;  // This should be possible
    var i: integer := i;  // But what about this?
    var k: integer := i;  // And this?
...
  end;

Again, Wirth decided not just to enforce a "variable must be declared before use" rule, but also broke ALGOL compatibility by moving variable to before a procedure/function's begin. I don't see much wrong with inline variables, they're reverting to the well-considered ALGOL-60 form.

MarkMLl

[munair]

Sometimes I have the feeling that I'm talking to a wall... For local variables it's technically absolutely no problem to implement this! It's removing a check and adding a loop and presto, you're done! (global variables would be another topic) Here. For those that want to play around with it I've attached a patch. I won't commit this however (aside the fact that it would also need to be added for global variables for consistency).

You are not talking to a wall as far as I'm concerned. From what I understood, it can be implemented, but it produces less optimal code. As per your words:

As you can see the initializations in the var section are implemented using constants, thus resulting in loads of global variables

So I assume, in order to fix that (if it were possible) would probably require serious refactoring. Not sure what the impact would be to do the same for global variables.

SharpBASIC uses a scopeless immediate constant table that eliminates duplicates and replaces all (constant) references, both global and local, with its respective table entry.

Code: Text  [Select][+][-]

1. ' SharpBASIC imm 1
2. ' ----------------
3. option strict;
4.  
5. decl sub test();
6.  
7. const pi = 314;
8. const pj = pi;
9.  
10. var a,b,c:int16 = pj;
11.  
12. main
13. do
14.   a = 314;
15. end;
16.  
17. sub test()
18.   const cc = 314;
19.   const cd = pi;
20. do
21.   //...
22. end;

without additional optimization:

Code: ASM  [Select][+][-]

1. ; ...
2. _I0:
3.         push    ebp
4.         mov     ebp, esp
5.         sub     esp, 8
6. ; define cc
7.         movsx   eax, word [_C0]
8. ; save cc
9.         mov     [ebp - 4], ax
10. ; define cd
11.         movsx   eax, word [_C0]
12. ; save cd
13.         mov     [ebp - 8], ax
14. ._L0:
15.         mov     esp, ebp
16.         pop     ebp
17.         ret
18.  
19. ; global definitions
20.  
21. SECTION .rodata
22.  
23. _C0                 dw 314
24.  
25. SECTION .data
26.  
27. ; define a
28. _I3                 dw _C0
29. ; define b
30. _I4                 dw _C0
31. ; define c
32. _I5                 dw _C0

[PascalDragon]

Sometimes I have the feeling that I'm talking to a wall... For local variables it's technically absolutely no problem to implement this! It's removing a check and adding a loop and presto, you're done! (global variables would be another topic) Here. For those that want to play around with it I've attached a patch. I won't commit this however (aside the fact that it would also need to be added for global variables for consistency).

You are not talking to a wall as far as I'm concerned. From what I understood, it can be implemented, but it produces less optimal code. As per your words:

As you can see the initializations in the var section are implemented using constants, thus resulting in loads of global variables

So I assume, in order to fix that (if it were possible) would probably require serious refactoring. Not sure what the impact would be to do the same for global variables.

You wrote this:

Today I implemented immediate constants in the SharpBASIC compiler, which reminded me of this feature request that appears not easy to implement because of FPC's code reuse involving constants.

This does not talk about optimization, this talks about implementing this feature. And completely independent of what code is produced by the compiler the feature itself can be easily added at least for local variables which can be seen in the patch I posted. So again, it is easy to implement. The generated code is a completely different matter.

[munair]

You wrote this:

Today I implemented immediate constants in the SharpBASIC compiler, which reminded me of this feature request that appears not easy to implement because of FPC's code reuse involving constants.

This does not talk about optimization, this talks about implementing this feature. And completely independent of what code is produced by the compiler the feature itself can be easily added at least for local variables which can be seen in the patch I posted. So again, it is easy to implement. The generated code is a completely different matter.

Code reuse sounds pretty much like an optimization issue to me, but I admit, it was a poor choice of words, easy to misinterpret. I apologize if I did not express myself more clearly.

[440bx]

A for-do statement doesn't have to make use of its index variable inside the block being controlled, hence there's no requirement that the index variable be visible.

You're right, it doesn't.

Therefore ISTM that the correct behaviour would be for the newly-declared i to be distinct from the index variable: it doesn't take the same value, and changing it doesn't (of course) affect the iteration.

After I thought a little bit about it, I came to that conclusion too but, as other forum members reported, Rio declares it a duplicate identifier.

My biggest problem with the Delphi implementation of inline variables is that it isn't always obvious what the visibility scope of a variable is. An example is that "for" loop, strictly speaking, the compiler should not be issuing a "duplicate identifier" error but, reportedly it does.  The other thing I dislike a great deal about it is, the ability to declare variables anywhere.  It's totally counter to what programming should be, which is: organized code and data.    The compiler allowing variable declarations to occur just about anywhere is a data declaration "goto" because when reading the code and seeing a variable name, the programmer cannot go to a single location where all variables (within the scope) are declared, instead the programmer has to inspect every line of code because each one of them may be a variable declaration that masks a previous declaration.  I can't help thinking ... who is designing this cr*p ?. Of course, the answer is, a company who is a lot more interested in making money than designing a good programming language.

I don't see much wrong with inline variables, they're reverting to the well-considered ALGOL-60 form.

They encourage messy and poorly organized code.

I like and support the ability to define scopes as necessary but, where they start, where they end and their internal structure has to be crystal clear, otherwise it's just another way of making a mess.

I can only guess but, I have a feeling Wirth made Pascal strict about where variables could be declared because he probably saw a lot of hard to understand code due to casual use of inline variable declarations.

[munair]

My biggest problem with the Delphi implementation of inline variables is that it isn't always obvious what the visibility scope of a variable is.

I don't see much wrong with inline variables, they're reverting to the well-considered ALGOL-60 form.

They encourage messy and poorly organized code.

I totally agree with 440bx. The complexity, overhead (compiler-wise) and confusion (programmer-wise) outweigh the benefits.

In general, having all declarations in one section gives a non-trivial overview and is easier/faster for the compiler to process.

[Zoran]

Plus it is not important to me. Unlike the intrinsic you implemented some time ago, which I would really use a lot, but it was finally rejected.

My current idea is that it will make a comeback as an if … then … else expression (which I had implemented as a proof of concept before that already as well).

Thank you! Looking forward for it!