FPC Feature request/suggestion

[munair]

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.

The following SB code:

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

1. ' SharpBASIC real 1
2. ' -----------------
3. const pi = 3.14;
4.  
5. var a,b,c:real32 = 3.14;
6. var e,f,g:real32 = pi;    ' same effect
7. var r: real32;
8.  
9. main
10. do
11.   r = 3.14;
12. end;

generates the following asm without optimization (32 bits):

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

1. SECTION .text
2.  
3. global  _start
4. global  _end
5.  
6. _start:
7.         fld     dword [_M0]
8. ; save r
9.         fst     dword [_I7]
10. _end:
11.         mov     ebx, 0
12.         mov     eax, 1
13.         int     80h
14.  
15. SECTION .rodata
16.  
17. _M0                 dd 3.14
18. ; define pi
19. _I0                 dd _M0
20.  
21. SECTION .data
22.  
23. ; define a
24. _I1                 dd _M0
25. ; define b
26. _I2                 dd _M0
27. ; define c
28. _I3                 dd _M0
29. ; define e
30. _I4                 dd _M0
31. ; define f
32. _I5                 dd _M0
33. ; define g
34. _I6                 dd _M0
35.  
36. SECTION .bss
37.  
38. ; define r
39. _I7                 resd 1

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.

[piola]

I've also been wondering why multiple variable initialization ain't possible. It's a feature I would appreciate, too.

But much more than that I would love to have a loop-locale variable declaration, e.g.

FOR i: Integer=0 TO 10 DO ...
WHILE (i: Integer = 0) < 80 DO ...

How are chances for this extension? The variable's scope should be restricted to the loop, of course.

[Martin_fr]

But much more than that I would love to have a loop-locale variable declaration, e.g.

FOR i: Integer=0 TO 10 DO ...
WHILE (i: Integer = 0) < 80 DO ...

How are chances for this extension? The variable's scope should be restricted to the loop, of course.

Search the forum. That has been fiercely discussed.

[piola]

Ok, sorry, I have searched but probably used the wrong keywords. Sorry for asking again.

[440bx]

<snip> at this point it may require too much refactoring to get it done.

I haven't looked at the FPC code that implements variable declaration parsing but, based on its behavior I have a guess that has a reasonable chance of being right, which is:

When parsing a single variable declaration, the parser can go linearly from variable name token, colon token, type token, equal token, value token.  Fully linear, very simple.  Quite likely there is a production to do just that.

For a variable group, it probably uses a recursive algorithm. On every comma, it recurses, when it finds the colon, it stops recursing and the current token should be the data type (reached when the colon was consumed.) At that point, it most likely starts unwinding the recursive calls and assigning the type it found and validated to all the variables it's holding in the recursive stack.  That's fairly simple and, it really doesn't add any significant amount of complexity to parse two more tokens (the equal and the value) and validate the value but, I suspect that the algorithm used to parse the variable group is used for something else too and, that is where the addition might cause problems, it may not be meaningful in that context.

Anyway... guess and speculation.  Bottom line: it's useless.

[flowCRANE]

But much more than that I would love to have a loop-locale variable declaration, e.g.

This is possible in Delphi — inline variable declaration. But not only for loops, also for any other local variables and constants. This allows you to write a code like in C-style languages, declare and initialize, with type inference. The greatest language extension I've ever seen — and I'm lovin' it.

But it has already been said that support of inline variable declaration will not be introduced, despite proclaiming that Delphi compatibility is very important.

[Zoran]

And if you don't want to, you don't have to use the new feature. It's so simple.

Oh, no! It is in no way so simple. Please, please never use this argument.
You cannot "not use" something. It is not much relevant if you use it when you yourself write some new code. You have to read and understand code written by other people. If it is allowed in a language, you have to use it.

[flowCRANE]

You have to read and understand code written by other people.

I know but, if other will commonly use a given feature, then it has been more useful and desirable than you expected.

Every day I analyze the code of others (mainly when it comes to RTL and LCL), which uses constructions, features and formatting that I don't use myself and which I consider not very trivial and readable. What can I do? Nothing, keep quiet and analyze still. There is no solution here — everyone writes the code in their own way.

You don't need extensions to write ugly code and you don't have to write ugly code using extensions.

[Zoran]

I know but, if other will commonly use a given feature, then it has been more useful and desirable than you expected.

You can write very nice and readable code in C++, but as soon you look into someone else's code, you will find "m = ++n" or similar lines all the times.
But everybody will always easier understand it written in two lines instead.
Still, people use it. Why? I really cannot think of any other explanation except that some people think they are smarter if code is shorter.

So, the problem is that language allows these horrible shortcuts.

Every day I analyze the code of others (mainly when it comes to RTL and LCL), which uses constructions, features and formatting that I don't use myself and which I consider not very trivial and readable. What can I do? Nothing, keep quiet and analyze still.

I also find FPC's code formatting style very strange.

Believe me, you don't need extensions to write ugly code.

But they will help it a lot.

[jamie]

I like the use of the ++ in loop controls in C...

You can define if you want the counter incremented before or after the loop

left side - before the loop, right side- after the loop

 In other cases it really does not matter... if its on the left of right, ether way it will get incremented..

 ++X, X++ etc


Don't get me wrong, I wouldn't suggest this in fpc because the language really has no place for it, it works well in C though.

[440bx]

I was looking at that page about inline variables @furious programming linked to and found one example that could potentially generate quite a bit of trouble.  The sample they give is:

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

1. procedure ForTest;
2. begin
3.   var total := 0;
4.  
5.   for var I: Integer := 1 to 10 do
6.     Inc (Total, I);
7. end;
8.  

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.

[jamie]

So what you are saying is it handles inline variables.?

well, seeing that any variable within a FOR LOOP created should keep its scope there.

That would only make sense..

For the same reason that you would do the loop counter inline since its not suppose to be used outside the loop counter...

 I think what is happening here that a few are flying off the handle with negative responses that have the power to do it before even really studying it.

 Personally I don't line inline variables just anywhere but I guess If a LOOP counter could be considered as another scope level then that would make sense


TO answer the question of scope, in that example I would think If the compiler didn't bark about duplication then it would use the last variable declared...

[eljo]

I was looking at that page about inline variables @furious programming linked to and found one example that could potentially generate quite a bit of trouble.  The sample they give is:

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

1. procedure ForTest;
2. begin
3.   var total := 0;
4.  
5.   for var I: Integer := 1 to 10 do
6.     Inc (Total, I);
7. end;
8.  

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.  

I guess the second declaration will raise an "identifier redeclared" error since the first one is already valid in the current scope. Its not like an embedded procedure/function where the level of scope changes.

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.

The community edition of the latest delphi version can be downloaded and used for that kind of research freely it just requires a internet connection once a year to "refresh" the license when it expires.

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.

[440bx]

it would use the last variable declared...

Now that you mention it, I think you're right.  It would no longer see "I" as the index variable and simply use the one in scope.  That could easily confuse whoever reads that code.

I guess the second declaration will raise an "identifier redeclared" error since the first one is already valid in the current scope. Its not like an embedded procedure/function where the level of scope changes.

Now that I've thought more about it, I am fairly sure the "for" and, its index variable, are one scope above the begin/end scope.  That's what makes sense.

The community edition of the latest delphi version can be downloaded and used for that kind of research freely it just requires a internet connection once a year to "refresh" the license when it expires.

Thank you, I appreciate the suggestion.  Aside from rare occasions like this one that are simply to fulfill my curiosity, I neither need it nor want it.

... 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 ?

[jamie]

Dixie cups and string!