Recent

Author Topic: New language features?  (Read 20476 times)

domasz

  • Hero Member
  • *****
  • Posts: 546
Re: New language features?
« Reply #150 on: September 29, 2024, 08:52:29 pm »
Please, no JavaScript bullshit in Pascal. Inline declaration of functions is retarded.

Warfley

  • Hero Member
  • *****
  • Posts: 1664
Re: New language features?
« Reply #151 on: September 29, 2024, 09:54:17 pm »
Incorrect, inline variables are about lifecycle too, not only for the HL visibility rules. They must be created/destroyed immediately after entering/leaving their scope/compound, otherwise they will be equally useless, imagine auto_ptr<> equivalent.

I mean... it would make sense to build it like that, but thats not necessarily the case. Currently FPC has no concept of scope related lifetime. Example:
Code: Pascal  [Select][+][-]
  1. type
  2.   generic TAutoFree<T: TObject> = record
  3.     ptr: T;
  4.     class operator Finalize(var rec: specialize TAutoFree<T>);
  5. end;
  6.  
  7. class operator TAutoFree.Finalize(var rec: specialize TAutoFree<T>);
  8. begin
  9.   rec.ptr.Free;
  10. end;
  11.  
  12. generic function AutoFree<T: TObject>(AObject: T): specialize TAutoFree<T>;
  13. begin
  14.   Result.ptr := AObject;
  15. end;
  16.  
  17. // Usage
  18. procedure Foo;
  19. begin
  20.   // ...
  21.   With specialize AutoFree<TStringList>(TStringList.Create) do
  22.   begin
  23.     ptr.Add('Hello');
  24.     ptr.Add('World');
  25.     ptr.SaveToFile('test.txt');
  26.   end;
  27.   // ...
  28. end;
Here a new scope is introduced where the temporary object of the AutoFree call lives, and access to ptr is granted. But even though the scope is limited, the actual lifetime will still be that of the function (well its undefined, but in experiments the FPC does it this way).

So just adding scoping is easy, as I showed some time ago, a rough implementation of inline variables can be done in a few hours. But this does not mean we get also scoped lifetimes and stuff like that.
Scoped lifetimes need a much more thorough change to the FPC than "simple" inline variables do.

Hello,
@Ryan J if you want inline variables there is a solution with anonymous procedure:
And if you're very lazy you can even write a macro:
Code: Pascal  [Select][+][-]
  1. {$Macros On}
  2.  
  3. {$Macro inlinevar:=TProcedure(procedure var}
  4. {$Macro vend:=end)()}
  5. // Usage
  6.   inlinevar i, j: Integer;
  7.   begin
  8.     // use inline vars here
  9.   vend;

And I think in mode MacPas you can even export macros, making it includable.

gidesa

  • Full Member
  • ***
  • Posts: 125
Re: New language features?
« Reply #152 on: September 30, 2024, 01:31:17 pm »
And if you're very lazy you can even write a macro:
Code: Pascal  [Select][+][-]
  1. {$Macros On}
  2.  
  3. {$Macro inlinevar:=TProcedure(procedure var}
  4. {$Macro vend:=end)()}
  5. // Usage
  6.   inlinevar i, j: Integer;
  7.   begin
  8.     // use inline vars here
  9.   vend;

And I think in mode MacPas you can even export macros, making it includable.

Thank you! I was thinking to a preprocessor to simplify syntax, but macro is just here
to help.


Thaddy

  • Hero Member
  • *****
  • Posts: 15933
  • Censorship about opinions does not belong here.
Re: New language features?
« Reply #153 on: September 30, 2024, 01:38:23 pm »
Still, you should not use it  :o , however briliant the macro is, KUDOS, Warfley!
« Last Edit: September 30, 2024, 01:48:32 pm by Thaddy »
If I smell bad code it usually is bad code and that includes my own code.

gidesa

  • Full Member
  • ***
  • Posts: 125
Re: New language features?
« Reply #154 on: September 30, 2024, 02:17:50 pm »
I am not a fan of inline variables. Although many great and little languages, carefully designed or throwaway, have it.
But it's a nice demonstration  that anonymous functions, and generics too (and macro!), are very powerful tools

BeniBela

  • Hero Member
  • *****
  • Posts: 918
    • homepage
Re: New language features?
« Reply #155 on: September 30, 2024, 03:22:11 pm »
Hello,
@Ryan J if you want inline variables there is a solution with anonymous procedure:

but these procedures make heap allocations. Cannot have that in high performance code

I mean... it would make sense to build it like that, but thats not necessarily the case. Currently FPC has no concept of scope related lifetime. Example:
Code: Pascal  [Select][+][-]
  1. type
  2.   generic TAutoFree<T: TObject> = record
  3.     ptr: T;
  4.     class operator Finalize(var rec: specialize TAutoFree<T>);
  5. end;
  6.  
  7. class operator TAutoFree.Finalize(var rec: specialize TAutoFree<T>);
  8. begin
  9.   rec.ptr.Free;
  10. end;
  11.  
  12. generic function AutoFree<T: TObject>(AObject: T): specialize TAutoFree<T>;
  13. begin
  14.   Result.ptr := AObject;
  15. end;
  16.  
  17. // Usage
  18. procedure Foo;
  19. begin
  20.   // ...
  21.   With specialize AutoFree<TStringList>(TStringList.Create) do
  22.   begin
  23.     ptr.Add('Hello');
  24.     ptr.Add('World');
  25.     ptr.SaveToFile('test.txt');
  26.   end;
  27.   // ...
  28. end;
Here a new scope is introduced where the temporary object of the AutoFree call lives, and access to ptr is granted. But even though the scope is limited, the actual lifetime will still be that of the function (well its undefined, but in experiments the FPC does it this way).

so, that crashes

I guess because AutoFree has no initializer and there is a temporary AutoFree variable created, whose ptr is uninitialized




Ryan J

  • Full Member
  • ***
  • Posts: 138
Re: New language features?
« Reply #156 on: September 30, 2024, 04:54:56 pm »
Anonymous procedures don't make allocations unless they are assigned to a function reference.

Warfley

  • Hero Member
  • *****
  • Posts: 1664
Re: New language features?
« Reply #157 on: September 30, 2024, 06:37:26 pm »
so, that crashes

I guess because AutoFree has no initializer and there is a temporary AutoFree variable created, whose ptr is uninitialized
Yeah I just typed that down without any tests or something, but you could just use some smart/unique pointer implementation thats around. Was just to visualize the point.
It was something I tested out some time ago when management operators where new, if with enforces lifetime, but (sadly) it doesn't.

Because I think if we make the argument that inline variables should be implemented for limiting lifetime using scopes, it shouldn't be inline variables, but with statements (similar to pythons with):
Code: Pascal  [Select][+][-]
  1. with TStringList.Create as sl do
  2.   // use sl
  3. // after with block sl will be freed automatically

wizzwizz4

  • New Member
  • *
  • Posts: 20
Re: New language features?
« Reply #158 on: September 30, 2024, 07:29:34 pm »
the loop could have further statements after the "list.free". So the exact same problem still exists.

One correct solution to this problem is a substructural type system. You can implement this on top of Pascal using static analysis. There is no reason to change the syntax – and this is one of the things that makes Pascal recognisably Pascal, so I don't know why you'd want to change it. (What next? Early return?)

Joanna from IRC

  • Hero Member
  • *****
  • Posts: 1174
Re: New language features?
« Reply #159 on: October 01, 2024, 02:35:25 am »
Please, no JavaScript bullshit in Pascal. Inline declaration of functions is retarded.
I agree. Let’s not try to imitate trendy languages too much. I’m happy with pascal as it is.
✨ 🙋🏻‍♀️ More Pascal enthusiasts are needed on IRC .. https://libera.chat/guides/ IRC.LIBERA.CHAT  Ports [6667 plaintext ] or [6697 secure] channel #fpc  #pascal Please private Message me if you have any questions or need assistance. 💁🏻‍♀️

PascalDragon

  • Hero Member
  • *****
  • Posts: 5723
  • Compiler Developer
Re: New language features?
« Reply #160 on: October 01, 2024, 11:22:17 pm »
@Ryan J if you want inline variables there is a solution with anonymous procedure:

Code: Pascal  [Select][+][-]
  1. // test inline variables
  2. // require FPC 3.3.1 or higher
  3. program Project1;
  4. {$MODE Delphi}
  5.  
  6. uses
  7.   SysUtils;
  8. var
  9.   x: Integer ;
  10. begin
  11.   x:=12;
  12.  
  13.   TProcedure(procedure
  14.   var
  15.      z: string;
  16.   begin
  17.     z:='Test inline ';
  18.     writeln('Hello! '+z+IntToStr(x));
  19.   end
  20.     )();  // note the "()" to soon execute the procedure
  21.  
  22. //  writeln(z);   // compiler error: identifier not found "z"
  23.   readln;
  24.  
  25. end.  

The TProcedure() is not required, the following is enough:

Code: Pascal  [Select][+][-]
  1. procedure
  2.   var
  3.      z: string;
  4.   begin
  5.     z:='Test inline ';
  6.     writeln('Hello! '+z+IntToStr(x));
  7.   end(); // note the ()!

Hello,
@Ryan J if you want inline variables there is a solution with anonymous procedure:

but these procedures make heap allocations. Cannot have that in high performance code

As Ryan J said, if an anonymous function isn't assigned to a function reference then there won't be any heap allocation happening (only in FPC however, Delphi always goes through a function reference). In this case the compiler will essentially treat it as a nested function.

gidesa

  • Full Member
  • ***
  • Posts: 125
Re: New language features?
« Reply #161 on: October 02, 2024, 01:08:52 pm »

The TProcedure() is not required, the following is enough:

Code: Pascal  [Select][+][-]
  1. procedure
  2.   var
  3.      z: string;
  4.   begin
  5.     z:='Test inline ';
  6.     writeln('Hello! '+z+IntToStr(x));
  7.   end(); // note the ()!

Thanks

As Ryan J said, if an anonymous function isn't assigned to a function reference then there won't be any heap allocation happening (only in FPC however, Delphi always goes through a function reference). In this case the compiler will essentially treat it as a nested function.

So performance are the same with nested function/procedure, or anonymous inline function/procedure. Isn't?



Ryan J

  • Full Member
  • ***
  • Posts: 138
Re: New language features?
« Reply #162 on: October 03, 2024, 06:09:27 am »
So performance are the same with nested function/procedure, or anonymous inline function/procedure. Isn't?

In general but I don't think FPC can inline any nested functions, or least not last time I checked.

Bogen85

  • Hero Member
  • *****
  • Posts: 661
Re: New language features?
« Reply #163 on: October 03, 2024, 10:16:14 am »
So performance are the same with nested function/procedure, or anonymous inline function/procedure. Isn't?

In general but I don't think FPC can inline any nested functions, or least not last time I checked.

From what I understood they can be inlined. I need to find a reply from Thaddy in a post where he talks about that. (Though if it was not in referenced to nested, then my memory serves me wrong)
« Last Edit: October 03, 2024, 10:35:11 am by Bogen85 »

Bogen85

  • Hero Member
  • *****
  • Posts: 661
Re: New language features?
« Reply #164 on: October 03, 2024, 10:45:06 am »
Either way, this issue keeps coming up (inline variables) (ok, multiple use of the inline term being thrown around here.

It is only possible in very recent versions of Delphi. I hope it does not make it into FPC.

It does not need to ever make it into FPC.

The same thing can already be achieved in FPC.

Yeah, introducing a new procedure is one way. But I want to limit the scope to a block. That's why I emphasized _block_ in my OP.

Using a procedure means, it's going to reserve a whole new context on the stack, eh? I don't want this.

So there's the inline modifier copying the procedure's body to the place where it's called. Huh. Uhm. That's a sub-optimal solution: Normally you'd introduce procedures if they're either called multiple times or they serve a well-defined task. This is not necessarily the case.

No!@@! I explained that by declaring the procedure *inline* you achieve *block* scoping, as can be seen from the assembler output. If it is just the eye candy of just *declaring* a variable in block scope? That doesn't add any value regarding generated code efficiency and there are plugins available for *editors* that can do just that for Delphi. I am not sure about Lazarus, but I won't be surprised if it is available.  The advantage over C's lazy typing is that in Pascal a separate procedure leads to easier to maintain sourcecode. Which is, btw, of course also possible in modern C.
There is no obvious reason to add bad coding habits to Pascal, imnsho.

As you have pointed out several times in other posts.

Once I saw all your replies on the issue and put it in practice in my own code, I saw no reason for that to come to FPC.

 

TinyPortal © 2005-2018