New language features?

[silvestre]

Very interesting your work, I hope it will be taken into account.

Obviously the indiscriminate use of this feature breaks the philosophy of pascal, but in some concrete cases it makes sense to use inline variables, for example certain loops in which only a temporary variable is going to be used.

The issue of porting code from other languages to pascal as someone has commented here in the case of C, is also quite interesting.

For me it gains in weight the freedom for a sensible use of each programmer, and to be able to enable this feature. It would also improve the (Delphi mode of the compiler.) Only the last point is quite relevant, a Delphi mode must be compatible with Delphi.

How much effort would it take to implement inline variables? When I was modifying compiler source to disable/overwrite/mangle/shorten RTTI as much as possible because I so hate it what I saw was codebase so huge, complex, so hard to change, so hard to add a new feature, to extend syntax. Commits on gitlab are mostly little bugfixes for RTL, nothing going on with the compiler itself.

Delphi has them for 5 years.

To answer your question more precisely, it took me around 1 hour to build the attached patch, which compiles the following:

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

1. program Test;
2.  
3. {$Mode ObjFPC}{$H+}
4. {$ModeSwitch InlineVariables}
5.  
6. var
7.   x: Double;
8. begin
9.   Write('Enter Float: ');
10.   ReadLn(x);
11.   WriteLn('Entered: ', x);
12.  
13.   begin
14.     Write('Enter Integer: ');
15.     var x: Integer;
16.     ReadLn(x);
17.     WriteLn('Entered: ', x);
18.   end;
19.  
20.  
21.   begin
22.     Write('Enter String: ');
23.     var x: String;
24.     ReadLn(x);
25.     WriteLn('Entered: ', x);
26.   end;
27.  
28. end.

Note, I haven't written any test cases aside the above or ran the existing tests so this will probably break something.

PS: I still don't like the idea, but this sort of thing is just a fun little thing to do

[Fibonacci]

To answer your question more precisely, it took me around 1 hour to build the attached patch, which compiles the following:

Impressive.

First, I had problems with the .patch file. It had BOM header and git wasnt able to parse it (unrecognized input), after I removed it, it patched.

Second, couldnt compile FPC trunk:

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

1. ppc386.exe -Ur -Xs -O2 -n -Fu.. -Futrunk/fpcsrc/rtl/units/i386-win32 -FE. -FUunits/i386-win32 -dRELEASE ppuutils/ppudump.pp -Fu../llvm -Fu../generic -dGENERIC_CPU -Fi..
2. ppudump.pp(2455,8) Error: Expected another 1 array elements
3. ppudump.pp(5317) Fatal: There were 1 errors compiling module, stopping
4. Fatal: Compilation aborted

Added "m_inline_variables" to modeswitchname array at line 2455 of ppudump.pp and it compiled.

Kind of works, but for Strings it crashes. Access Violation.

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

1. var a: array[0..99] of char;

Compilation raised exception internally
An unhandled exception occurred at $00000000

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

1. var x: integer = 1;

Syntax error

Much work left to do it right, but you proved something, GJ.

[Warfley]

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

1. var x: integer = 1;

Syntax error

Much work left to do it right, but you proved something, GJ.

I must admit, I cheated a bit with that one, because I saw that adding functionality for doing the assignment would have been much more effort, as I could not simply reuse the existing variable declaration parsing function with little changes, like I did here.

So yes it's much more work, but conceptiually it's not that hard

[jamie]

I have an idea for a compiler enhancement. I am sure it will never make it pass the guard dog.

The Default parameters in a call block only accept constants where it would be nice if we could specify a function instead.

For example:

  MyProcedure Test(SomeString:string; DataIndex:Integer := GetcurrentDataIndexFromAFunction);

 or did I miss something?

[Fibonacci]

The Default parameters in a call block only accept constants where it would be nice if we could specify a function instead.

And this function should be called once or everytime the function is called? If once, then in interfaces section or implementation?

MyProcedure Test(SomeString:string; DataIndex:Integer := GetcurrentDataIndexFromAFunction);

I assume it would need to get the value for DataIndex everytime Test is called. Looks like much effort to implement for not so much value.

I have another idea, if a procedure has optional parameters like:

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

1. procedure test(A: integer=1; B: integer=2; C: integer=3);

And I want to call it with default values but only change C parameter, I should be able to do it with:

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

1. test(C := 42); //all default, just change C
2.  
3. test(1, C := 42); //B remains default

Or for ease of implementation, if parameter value is not given, use default:

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

1. test(, , 42);
2.  
3. test(1, , 42);

[domasz]

How about

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

1. test(default, default, 42);
2.  
3. test(1, default, 42);

[/quote]
or some other keyword?

[Fibonacci]

default or any other keyword would be ok I guess. Just te ability to do this would be useful.

[Warfley]

How about

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

1. test(default, default, 42);
2.  
3. test(1, default, 42);

or some other keyword?

This is dangerous because it can lead to errors when the function signature is changed, take the following example:

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

1. procedure Test(A: Integer = 0; B: Integer = 0);

And later someone amends it with:

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

1. procedure Test(const AName: String = ''; A: Integer = 0; B: Integer = 0);

If you have the following callsite code:

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

1. Test(0, 42);

The compiler will throw an error because the types don't match the new function signature. But if you would have a type ambigous value like default:

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

1. Test(default, 42);

would compile, but instead of setting B, it is now setting A and ignoring B.

Default values for parameters are already dangerous in itself (I once encountered a bug in a program that has laid dorment for probably years, because it was a function taking all integer arguments with all default values, and when one parameter was added, all callsites didn't match up anymore), but with strong typing, and under the assumptions that most of the parameters are of different types the risk can be avoided (still I try to avoid having more than one parameter of the same type with a default value directly next to each other because of this).

I think if you want to do something like this, named parameters on the callsite are the way to go, as it is much more robust to errors, and frankly also easier to understand.

[Fibonacci]

How about implementing heredoc (here-text, here-string, here-script...)?

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

1. var
2.   s: string;
3. begin
4.   s := <<<THIS_UNIQUE_ID_ENDS_HEREDOC
5.   multiline string
6.   another line
7.     this line will have 2 spaces indent
8.   last line
9.   THIS_UNIQUE_ID_ENDS_HEREDOC;
10.  
11.   writeln('string is: ', s);

[marcov]

Something is being discussed due to Delphi rumoured to be getting a similar feature. Best wait how that works out before we introduce alternate syntaxes.

There is also a lot of discussion about how to deal with whitespace, linefeeds and encodings and escaping the start/stop tokens.

For me it is mostly shader code, but I have that in resource files and kind of like having it in standalone, independent  files in SVN.

[Fibonacci]

Something is being discussed due to Delphi rumoured to be getting a similar feature.

Didnt know that. I dont use Delphi nor follow its news. Just recently I found out it has had inline variables for 5 years

[marcov]

Something is being discussed due to Delphi rumoured to be getting a similar feature.

Didnt know that. I dont use Delphi nor follow its news. Just recently I found out it has had inline variables for 5 years

Yes. And back then we decided to postpone that for Free Pascal, because there was a lot of discussion

Delphi seems to be implementing anything, probably to keep the subscription gravy train running lately. Most of these features are really low grade but visible stuff, great for forum discussions and language-design-by-mob.

[jamie]

I've gotten accustomed to using D's inline Variable definition for the FOR ... LOOP control, it keeps the scope local for the FOR loop since you are not supposed to use it outside of the loop.

[marcov]

I've gotten accustomed to using D's inline Variable definition for the FOR ... LOOP control, it keeps the scope local for the FOR loop since you are not supposed to use it outside of the loop.

IMHO not worth new syntax and dealing with inline variables and all their trouble in general. It all requires developer time, not just to develop the feature, but also the bunch of bugreports about bad interactions with other features.

[Ryan J]

How about implementing heredoc (here-text, here-string, here-script...)?

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

1. var
2.   s: string;
3. begin
4.   s := <<<THIS_UNIQUE_ID_ENDS_HEREDOC
5.   multiline string
6.   another line
7.     this line will have 2 spaces indent
8.   last line
9.   THIS_UNIQUE_ID_ENDS_HEREDOC;
10.  
11.   writeln('string is: ', s);

There has been a patch for multiline strings (using back ticks) which has gone ignored for 4 years I believe. I can't understand how this is possibly being rejected since it's so obviously useful and battle tested in so may other languages. yes I know the white space etc... but many use cases are for nested code like SQL, GLSL where whitespace doesn't matter so there's literally no downside.