FPC Feature request/suggestion

[MarkMLl]

Pascal chose to have it the other way around (two-character operator for assignment, and one character operator for comparison), which is fine too.

As both Roman and myself have said, that wasn't a choice: := was a digraph for the left arrow (just as C/C++ has digraphs and trigraphs for some characters today). It goes back all the way to ALGOL-60 and 6-bit character sets, which typically were uppercase-only but had a half-dozen or so characters which were originally used in ALGOL (I don't think FORTRAN etc. used them). See https://en.wikipedia.org/wiki/BCD_(character_encoding)#Burroughs_B5500_BCD_code in particular.

And then customers started buying IBM 026 and 029 cardpunches, which didn't support those characters and resulted in the introduction of digraphs in fairly short order.

Wirth chose  { }  as the comment delimiter fairly early on, and initially allowed  /* */  as digraphs before moving to  (* *)  with which everybody is, of course, familiar. However I don't think it's safe to say that those are still digraphs, since if they were you could open a comment with  {  and close it with  *)

MarkMLl

[jamie]

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

1. unit1.pas:47                              A := 0; B := 0; C := 0; d := 0; e := 0; f:= 0; g:= 0;
2. 000000010002CC49 b800000000               mov    $0x0,%eax
3. 000000010002CC4E b800000000               mov    $0x0,%eax
4. 000000010002CC53 b800000000               mov    $0x0,%eax
5. 000000010002CC58 b800000000               mov    $0x0,%eax
6. 000000010002CC5D b800000000               mov    $0x0,%eax
7. 000000010002CC62 b800000000               mov    $0x0,%eax
8. 000000010002CC67 b800000000               mov    $0x0,%eax
9. unit1.pas:48                              If (A=0) or (b = 0) or (c= 0) or (d=0) or (e = 0) or (f= 0) or (g = 0) then exit;
10.  
11.  

I was asked If I compiled with options, yes this was done at level 4...
I did long Boolean operation to ensure the compiler didn't drop It out.

Looks buggy to me ?

[jamie]

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

1. unit1.pas:47                              A := 0; B := 0; C := 0; d := 0; e := 0; f:= 0; g:= 0;
2. 000000010002CC69 b800000000               mov    $0x0,%eax
3. 000000010002CC6E b900000000               mov    $0x0,%ecx
4. 000000010002CC73 ba00000000               mov    $0x0,%edx
5. 000000010002CC78 41bb00000000             mov    $0x0,%r11d
6. 000000010002CC7E 41b800000000             mov    $0x0,%r8d
7. 000000010002CC84 41b900000000             mov    $0x0,%r9d
8. 000000010002CC8A 41ba00000000             mov    $0x0,%r10d
9. unit1.pas:48                              If (A=0) or (b = 0) or (c= 0) or (d=0) or (e = 0) or (f= 0) or (g = 0) then exit;
10. 000000010002CC90 85c0                     test   %eax,%eax
11.  
12.  

Level 2..

Level 3 and 4 generate the previous results.

Level 2 seems to work.

if this is still prevalent in current compiler could explain some unknowns happening.

[PascalDragon]

Looks buggy to me ?

Please show your code and what compiler version and target you are using. For me the following works correctly with both FPC 3.0.4 and trunk from no optimization to -O4 on both i386-win32 and x86_64-win64:

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

1. program tvarinit;
2.  
3. procedure Test;
4. var
5.   a, b, c, d, e, f, g: LongInt;
6. begin
7.   a := 0;
8.   b := 0;
9.   c := 0;
10.   d := 0;
11.   e := 0;
12.   f := 0;
13.   g := 0;
14.   Writeln(a, b, c, d, e, f, g);
15. end;
16.  
17. begin
18.   Test;
19. end.

[jamie]

I am not at my computer now but that was done on a windows
PC using laz gui 2.0.8
Just start a new gui app and put a button on the form implement
The onclick event.
Repeat those lines as showed but nothing else, just those two lines
In a button click event.
Experiment.
Have fun.

[Martin_fr]

Trunk gets a different result.

But that test is artificial. If you do unpredictable stuff with each var

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

1. {$INLINE off}
2. Procedure R(var a: integer); // needs a variable, not a value
3. begin
4.   a := a + random(9);
5. end;
6.  
7. ....
8.   a := 0;
9. ...
10.   f := 0;
11.   g := 0;
12.   R(a);
13.   R(b);
14. ....
15.   Writeln(a, b, c, d, e, f, g);

Then each var is forced back into existence.

Anyway this has nothing do to with the original topic. Even if clever wording can make it look like it does.

This is about the optimizer (it was suggested that a "string" asm op can be used to init all of the var in one go.)

The FPC optimizer obviously does not do this optimization.
There is no reason why it would starting to optimize different if the vars were initialized in the "var" section.

In fact, an optimizer relying on the user to use a specific syntax would be a very poor optimizer.
That is not to say, that an optimizer must recognize every possible syntax. That is impossible. But an optimizer should strive to recognize as many syntax as possible.
A sequence at the start of the code, is not much different from the "in var block". Both could be detected.

Adding the "in var initialization" should lead to the same asm code.

Improving the optimizer should work for current code, as well as for the "in var init" (if that exists)

Writing an optimizer that only works, if everyone rewrites their existing code, well that sound really weird to me.

[marcov]

Also note that Pascaldragon's code creates a procedure. He doesn't test with the main program and variables that are essentially globals because that is a different kind of optimization.

[440bx]

He doesn't test with the main program and variables that are essentially globals because that is a different kind of optimization.

In the case of globals, it's not even an optimization.  Just a value saved in the location reserved for the variable in the initialized data segment.

Honestly, it is a bit silly to require the programmer to have individual declarations for every variable when each variable is supposed to have the same initial value.    As should be obvious, the separate declarations give no indication that the group of variables _should_ have the same initial value.  IOW, not implementing that is counter to good programming practices.

Having initialized variable groups gives the programmer the ability to make it clear that every variable in that group should have the same initial value.   Without that capability, there is no indication (short of a comment somewhere) that they should have the same initial value.

[ASBzone]

Python alows for this too, and C-style assigning one value to many variables also. And the Go language too. Why modern languages are so poor designed and, at the same time, so popular? Rhetorical question.

In general, people are lazier today, and desire instant gratification more often than not.

People don't like planning.   I have this argument with my son every few days.  He likes Pascal, but loves Python more, and often emphasizes that it is all the structure that annoys him (I have failed as a parent!) 

And he manages to get away with flying by the seat of his pants for a while, but then will come a challenge that stumps him, and after a few days, he will grudgingly admit that if he had taken more time to plan, and had been less ad hoc, he would have been better off.

Then he gets back to instant gratification mode, and the cycle continues...       (There's some learning happening in there, but it is coming rather slowly, IMO)

[Martin_fr]

As should be obvious, the separate declarations give no indication that the group of variables _should_ have the same initial value.

If you want to express that the same initial value is more than coincidence, then the following would be good:

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

1. const
2.   NAMED_INIT_VAL = 0; // or some other val
3.   OTHER_INIT_VAL = 0; // same val, but different meaning
4. var
5.   a, b, c, d: integer; // could also be individual
6. begin
7.   a := NAMED_INIT_VAL;
8.   b := NAMED_INIT_VAL;
9.   c := NAMED_INIT_VAL;
10.   d := OTHER_INIT_VAL;
11. end;

Yes this is considerable more typing. It is considerable more verbose, and therefore more expressive as to what the intention of the author may be.

On the other hand

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

1. var
2.   a, b, c, d: integer = 0;

Still leaves it open, if that same value is coincident or not.
"0" could be an initial count, or a special marker, or a empty bitmask, or ..... And it could be a different one for each var.

Please note, my above statement is neither pro nor contra with regards to the "var a,b,c = 0" feature request.
I merely point out, that the quoted supposed pro argument, is IMHO indeed not an argument at all. (Or a very poor one at best).

[440bx]

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

1. const
2.   NAMED_INIT_VAL = 0; // or some other val
3.   OTHER_INIT_VAL = 0; // same val, but different meaning
4. var
5.   a, b, c, d: integer; // could also be individual
6. begin
7.   a := NAMED_INIT_VAL;
8.   b := NAMED_INIT_VAL;
9.   c := NAMED_INIT_VAL;
10.   d := OTHER_INIT_VAL;
11. end;

Yes this is considerable more typing. It is considerable more verbose, and therefore more expressive as to what the intention of the author may be.

But, it isn't a simple matter of more typing.  I am not against lots of typing, I like COBOL for instance and, nothing beats COBOL when it comes to typing a lot.

The problem with the construction above, is all the duplication.  Duplication is very undesirable because every duplicate has to be verified for consistency instead of having a single value to verify.   This is one of the foundations of database theory and one that has carried to some extent into programming.  If two code sequences are identical and associated with the same logical goal then, they should be made into a function/procedure so that if a change is needed, it need only be done in one place.  In one word: normalization.

I'm sorry but the example you showed is a very poor construction.  There is nothing preventing initializing one of the variables with OTHER_INIT_VAL instead of NAMED_INIT_VAL, while it is very _unlikely_ that an entire group of variables is going to be initialized to the wrong value.  Moreover, it is a rather common human mistake to duplicate too many times.  The construction you showed creates a situation where it is more likely that a variable will be given the wrong initial value as a result of the "autopilot" effect.... copy there... copy there... copy there... and then in the debugger... oops! shouldn't have copied there.  Too bad... but, there is hope, since the language has no support for variable group initialization, we can live and repeat the mistake.  Wonderful...

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

1. var
2.   a, b, c, d: integer = 0;

Still leaves it open, if that same value is coincident or not.
"0" could be an initial count, or a special marker, or a empty bitmask, or ..... And it could be a different one for each var.

If it is coincident then it doesn't belong in the same declaration.  It should be a separate declaration which _coincidentally_ happens to be initialized to the same value.  The fact that it is in a separate declaration is the indication that it is just coincidence that they have the same initial value (except in the case of initializing to zero which is "profilactic".)

I'll give you credit for one thing: you did provide an excellent example of a _very_ poor argument.  I'll add it to PascalDragon's which was in the same class.

[ASBzone]

However what escapes many here is that initialization in the var-section is less efficient than initializing in code:

 

I never realized this at all  (as I hardly peek at assembler these days)

[440bx]

However what escapes many here is that initialization in the var-section is less efficient than initializing in code:

 

I never realized this at all  (as I hardly peek at assembler these days)

In general, a programmer shouldn't have to be looking at the assembly code to verify that the compiler did a decent job.  It's the compiler's reason to exist to produce good code.  The programmer's reason to write software isn't to cater to the compiler (just like a car is supposed to transport the driver, it's not the driver who is supposed to push the car to the destination because that "optimizes" gasoline consumption - granted, it probably does but, selling the car and just walking there would be a better optimization for the driver.)  The programmer is _entitled_ to expect the compiler to produce good code.  That one syntactic structure leads to better optimizations than another one is simply an acknowledgement of a deficiency in the compiler.

[Zoran]

I am rather sceptical to the syntax proposals that we can often read in forum. That is because I have been here for more than ten years already, and I know by now that these proposal come too often and most of these are only syntax sugar, rarely they even care about backwards compatibility. Not many of these can pass the main conditions listed here.

However, I have to say, after reading all posts in this topic, that this is in my opinion an example of a proposal that is nothing but useful (although not very important).
It does not mean I will much use it, as I myself just don't use initialized variables, but when we have initialization in var section, it is quite natural to be able to initialize several variables to the same value as a group.

I really would not like to see tuple-like initialization introduced, as someone proposed in this thread; I agree with 440bx that that syntax is not very readable, but when it is initialization to one same value, I think it would be just natural feature.

It is not very important, so if it were difficult to implement, I think it would not be worth trouble.

But, after PascalDragon said that it is technically easy to implement, at first this seemed to me a valid argument against the proposed syntax:

The initialization will become rather lost if you have longer variable names and spread them across multiple lines (this coding style is used in the compiler for example):

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

1. var
2.   SomeVariableName1,
3.   SomeVariableName2,
4.   SomeVariableName3,
5.   SomeVariableName4,
6.   SomeVariableName5,
7.   SomeVariableName6,
8.   SomeVariableName7,
9.   SomeVariableName8,
10.   SomeVariableName9,
11.   SomeVariableName10: Integer = 255;

However, after I read the 440bx's response:

The initial value can't be "lost" without also "losing" the variable's data type.

I really have to fully agree with 440bx. The initialization won't be lost, you can lose it only if you lose the data type.

So, PascalDragon, I think your argument is weak.
I do not think you should spend much of your time on this, when you have more important things to do, but if it is not hard to implement, please do. I just don't agree with the reason you gave.

[PascalDragon]

The FPC optimizer obviously does not do this optimization.
There is no reason why it would starting to optimize different if the vars were initialized in the "var" section.

In fact, an optimizer relying on the user to use a specific syntax would be a very poor optimizer.
That is not to say, that an optimizer must recognize every possible syntax. That is impossible. But an optimizer should strive to recognize as many syntax as possible.
A sequence at the start of the code, is not much different from the "in var block". Both could be detected.

Adding the "in var initialization" should lead to the same asm code.

As mentioned above the initialization in the var section is handled by the same variable initialization mechanism as global variables thus you'll always have loads there while for the in-code initialization the compiler only has to deal with stores.

So, PascalDragon, I think your argument is weak.
I do not think you should spend much of your time on this, when you have more important things to do, but if it is not hard to implement, please do. I just don't agree with the reason you gave.

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