Recent

Author Topic: Question ?!!!!  (Read 4691 times)

nouzi

  • Full Member
  • ***
  • Posts: 132
« Last Edit: November 11, 2018, 02:09:56 pm by nouzi »
my english is  bad
Lazarus 2.0 free pascal 3.0.4
Lazarus trunk  free pascal trunk 
System : windows 7 64bit

howardpc

  • Hero Member
  • *****
  • Posts: 3150
Re: Question ?!!!!
« Reply #1 on: November 11, 2018, 02:38:38 pm »
FPC introduced initialisation of variables in their declaration long before Delphi.
One drawback of syntax sugars that, for example, make the compiler infer and allocate implicit types to variables, is that they inevitably slow the compiler slightly, and make it that bit more complex and more time-consuming/harder to maintain.

Not to mention that they move Pascal further away from its Wirthian type-safe declarative design.

Thaddy

  • Hero Member
  • *****
  • Posts: 8927
Re: Question ?!!!!
« Reply #2 on: November 11, 2018, 03:02:26 pm »
FPC introduced initialisation of variables in their declaration long before Delphi.
One drawback of syntax sugars that, for example, make the compiler infer and allocate implicit types to variables, is that they inevitably slow the compiler slightly, and make it that bit more complex and more time-consuming/harder to maintain.

Not to mention that they move Pascal further away from its Wirthian type-safe declarative design.
You're partially barking up the wrong tree, Howard. (Sorry, just let the dogs out  8-), actual dogs, two of them )
What he is referring to is:
Code: Pascal  [Select]
  1. program testinlinevars;
  2. begin
  3.   // imagine lots of previous code
  4.   for var i:integer := 1 to 10 do writeln(i);
  5. end.

Or even with type inference:
Code: Pascal  [Select]
  1. program testinlinevars;
  2. begin
  3.   for var i  := 1 to 10 do writeln(i);
  4. end.

Such code has been requested many times and always refused by the compiler team. In my opinion for all the right reasons.
Yes. The declarative design of Pascal is a feature and a huge asset. Working with C code bases for the last 30 years this kind of syntax should never be introduced and is often forbidden in huge C codebase examples like the Linux kernel.
« Last Edit: November 11, 2018, 03:44:53 pm by Thaddy »
Most people that want to use threading should learn to patch their jeans first: use a needle.

Handoko

  • Hero Member
  • *****
  • Posts: 3158
  • My goal: build my own game engine using Lazarus
Re: Question ?!!!!
« Reply #3 on: November 11, 2018, 03:09:27 pm »
The reasons for the rejection can be found here: (item #11)
http://wiki.freepascal.org/Modernised_Pascal

Thaddy

  • Hero Member
  • *****
  • Posts: 8927
Re: Question ?!!!!
« Reply #4 on: November 11, 2018, 03:12:14 pm »
The reasons for the rejection can be found here: (item #11)
http://wiki.freepascal.org/Modernised_Pascal
That's only one of the reasons. There are many more to be found on the dev mailing list. Or even the original papers on the design of the Pascal language by Niklaus Wirth.
« Last Edit: November 11, 2018, 03:13:54 pm by Thaddy »
Most people that want to use threading should learn to patch their jeans first: use a needle.

nouzi

  • Full Member
  • ***
  • Posts: 132
Re: Question ?!!!!
« Reply #5 on: November 11, 2018, 03:47:37 pm »
thank for all
my english is  bad
Lazarus 2.0 free pascal 3.0.4
Lazarus trunk  free pascal trunk 
System : windows 7 64bit

dpremus

  • New member
  • *
  • Posts: 6
Re: Question ?!!!!
« Reply #6 on: November 23, 2018, 08:04:07 pm »
I hope that we will never have inline variables in FPC.

This approach in C is used for having better performance, but now day compilers should be smart enough to optimize this.

This will introduce more mess in code than benefits.

Do we need Delphi compatibility anymore?

For example, you can't still use a string in Delphi "case" and they talk about language improvements.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7446
Re: Question ?!!!!
« Reply #7 on: November 23, 2018, 08:11:16 pm »
In the initial discussion I missed it, but the below illustrates the problem perfectly

Code: [Select]

procedure xxx.yyy;
var thisisastaticglobalvar : integer =0;
begin
  var thisisalocalvarbutthesyntaxisthesame: integer =0;
  ..
end;

Same syntax, two lines apart, meaning totally different. This is not just a dig at Embarcadero. The mode objfpc initialized variables just add to the confusion by recycling syntax for initialized local variables;

Code: [Select]
{$mode objfpc}
procedure xxx.yyy;
var weknoweverythingbetterandinfpcthisisaninitializedlocalvar  : integer =0;
begin
  var thisisalocalvarbutthesyntaxisthesame: integer =0;
  ..
end;

Sigh.

Moral of the story: don't recycle syntax for something potentially ambiguous.

"you don't have to use it if you don't like it" is NOT a good argument.
« Last Edit: November 23, 2018, 08:13:01 pm by marcov »

User137

  • Hero Member
  • *****
  • Posts: 1790
    • Nxpascal home
Re: Question ?!!!!
« Reply #8 on: November 23, 2018, 09:44:50 pm »
Not sure i understand the explanations. Variable scope is same, and this sort of thing is clearly restricted:
Code: Pascal  [Select]
  1. var
  2.   Form1: TForm1;
  3.   Form1: TStringList;
You'll get: Error: Duplicate identifier "Form1". Same should happen if you try to re-declare a variable inside a function, before or after the "begin" word.

Code: Pascal  [Select]
  1. procedure xxx.yyy;
  2. var i: integer = 0;
  3. begin
  4.   var i: integer =0; // Illegal!
  5.   var k: integer =0; // Ok.
  6.   for var n:integer := 1 to 10 do writeln(n); // Ok.
  7.   // variable n doesn't exist here anymore, but k does.
  8.   for var n:integer := 1 to 10 do writeln(n); // Ok.
  9. end;
« Last Edit: November 23, 2018, 09:50:52 pm by User137 »

jamie

  • Hero Member
  • *****
  • Posts: 1993
Re: Question ?!!!!
« Reply #9 on: November 23, 2018, 11:10:59 pm »
Random variable declaration is a bad idea, very sloppy code however, I do like the idea of
the FOR LOOP control being able to do this because of this simple fact. The loop variable is documented
as undefined out side the FOR LOOP so it would make perfect sense to allow this to take place within
the loop control where the code in the loop would be the only code that can see it.

 The FOR LOOP is not designed to allow the loop variable to be used outside so why not simply allow the
FOR loop control to create a localized variable as am option..

 The WHILE and REPEAT do reserve the ending value of the a loop while the FOR does not depending on what
the compiler decides to do .

 This is my argument unless you want to modify the FOR LOOP control to have a usable ending value when exiting the
block.



Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5633
    • wiki
Re: Question ?!!!!
« Reply #10 on: November 23, 2018, 11:44:57 pm »
Random variable declaration is a bad idea, very sloppy code however, I do like the idea of
the FOR LOOP control being able to do this because of this simple fact. The loop variable is documented
as undefined out side the FOR LOOP
IIRC, with the exception when the loop was exited by "break" or the like, in which case it is defined? (need to double check)

Beside search the many discussions on this forum, where there are plenty of reasons why even the for loop var would not be a good idea. (And yes, I did read the arguments that were brought in favour, and none prevailed)

And lastly, if the only concern is, not to accidentally use the var after the loop:
- the compiler should emit a "undefined warning" => if not that would be something that you should request. If it does, -we promote warnings to errors.
- and if that is not good enough, and you really think it needs changed syntax / extra features (I don't, but I humour the idea): in the var block on top "var a: TEnumerable loopcounter;" limit it to be used as loop counter, and only avail in loops in which it is a counter. I don't think that is needed, but it is far less problematic, and solves the problem.

BeniBela

  • Hero Member
  • *****
  • Posts: 680
    • homepage
Re: Question ?!!!!
« Reply #11 on: November 24, 2018, 12:34:24 am »
Delphi compatibility is important

All kinds of weird things were added for Delphi compatibility. classes, when there are already objects; interfaces; Delphi's generic syntax; codepage aware strings ...

This syntax should not be the reason to abandon Delphi compatibility

440bx

  • Hero Member
  • *****
  • Posts: 1129
Re: Question ?!!!!
« Reply #12 on: November 24, 2018, 01:33:20 am »
Do we need Delphi compatibility anymore?
More people should ask themselves that question.  The world is afraid of C/C++, that leads to choices like Delphi compatibility because of the (justified) fear that a better language would not stand a chance against the popularity that mediocre languages have gained.   Very unfortunate.
using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

PascalDragon

  • Hero Member
  • *****
  • Posts: 626
  • Compiler Developer
Re: Question ?!!!!
« Reply #13 on: November 24, 2018, 02:48:39 pm »
Delphi compatibility is important

All kinds of weird things were added for Delphi compatibility. classes, when there are already objects; interfaces; Delphi's generic syntax; codepage aware strings ...

This syntax should not be the reason to abandon Delphi compatibility
On the contrary. This syntax is a good reason to abandon Delphi compatibility, because unlike the ones you mentioned this one touches and chances the very core spirit of the Pascal language.

As such the opinion of the development team on this feature is that we will not implement this. FPC has a strong user base by itself as such we can be picky nowadays which nonsense of Delphi we accept and which we don't.

In the initial discussion I missed it, but the below illustrates the problem perfectly

Code: [Select]

procedure xxx.yyy;
var thisisastaticglobalvar : integer =0;
begin
  var thisisalocalvarbutthesyntaxisthesame: integer =0;
  ..
end;

Same syntax, two lines apart, meaning totally different. This is not just a dig at Embarcadero. The mode objfpc initialized variables just add to the confusion by recycling syntax for initialized local variables;

Code: [Select]
{$mode objfpc}
procedure xxx.yyy;
var weknoweverythingbetterandinfpcthisisaninitializedlocalvar  : integer =0;
begin
  var thisisalocalvarbutthesyntaxisthesame: integer =0;
  ..
end;

Sigh.

Moral of the story: don't recycle syntax for something potentially ambiguous.

"you don't have to use it if you don't like it" is NOT a good argument.
Ehm... where was this mentioned? The syntax for initializing inline variables in Delphi is
Code: Pascal  [Select]
  1. procedure xxx.yyy;
  2. begin
  3.   var thisisalocalvarbutthesyntaxisthesame: integer := {!} 0;
  4. end;
  5.  
(Note the ":=" instead of "=")

And where was it mentioned that Delphi now supports the following?
Code: Pascal  [Select]
  1. procedure xxx.yyy;
  2. var thisisastaticglobalvar : integer = 0;
  3. begin
  4. end;
  5.  
And that this is a global variable now merely by being initialized?
« Last Edit: November 24, 2018, 02:52:37 pm by PascalDragon »

Leledumbo

  • Hero Member
  • *****
  • Posts: 8108
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Question ?!!!!
« Reply #14 on: November 27, 2018, 09:04:08 pm »
As soon as this gets implemented, codetools will have to work harder by searching both declaration and execution section, just as your eyes do. Principle of locality in Pascal spirit is implemented through nested procedure, not inline declarations (and single called nested procedure should be inline-able automatically, zeroing the overhead).