Foo
Bar
Foo
Foo
Are the modeswitches already always on for $mode Delphi ?
Thanks to the development team. Will this new feature be available in the next release version of fpc?
I'm glad to see that it has finally arrived in FPC - good work! This should allow us to use several nice Delphi libraries with FPC. 8-)Not only that: FPC can do more as per PascalDragon's introductary notes...
I think you can also close the issue (https://gitlab.com/freepascal.org/fpc/source/-/issues/24481) now.
I think you can also close the issue (https://gitlab.com/freepascal.org/fpc/source/-/issues/24481) now.
I'm glad to see that it has finally arrived in FPC - good work! This should allow us to use several nice Delphi libraries with FPC. 8-)Not only that: FPC can do more as per PascalDragon's introductary notes...
I think you can also close the issue (https://gitlab.com/freepascal.org/fpc/source/-/issues/24481) now.
I have been toying with old D2009 and XE2 examples today and 90% can be made to work in minutes. Much more than I expected.
These defines can help others as well:The "warn 5036 off" is just to suppress a warning about the $capturer variable:
{$ifdef windows}{$apptype console}{$endif} {$mode delphi}{$modeswitch functionreferences}{$modeswitch anonymousfunctions} {$warn 5036 off}// "Warning: (5036) Local variable "$Capturer" does not seem to be initialized"
I suppose that will be fixed later? It does not really harm, but I sometimes like to compile with -Sew.
The warnings are on:
testanon.pas(51,1) Warning: (5036) Local variable "$Capturer" does not seem to be initialized
And on line 61 the same.
I compiled with -O4 and win64. It should be reproducible in main. With -02 there is no warning.
On linux32/64 debian the warning is also there with -O4
Any idea how to convert this to Object Pascal?
Under the assumption that the allocators only take one argument you can do it like this (this requires main due to the implicit function specialization):
QuoteUnder the assumption that the allocators only take one argument you can do it like this (this requires main due to the implicit function specialization):
Firstly I just joined the forum and I couldn't figure out how to reply by quoting selected text. Is this possible?
I just actually posted this exact same question on the FPC mail list before I saw this post. So it works with only one argument but why are arguments not allowed? The type is an undefined generic so it should work in theory and only consider the parameters when the function is specialize
For quoted reply I could copy and pasted but notice how it doesn't say who the quote was from. I expected to select some text and then hover the mouse over it and have an option to quote the selection. Pressing the quote button quotes the entire message which I think need to edit by hand.
The question was more about the undefined type and adding parameters like:
generic procedure Perform<T>(func: T); begin func(1); end;
I replied and CC'd you on the mail list also since we're both having problems getting messages. I'm using a gmail account btw because my private domain was blocked (Jonas discovered this some years ago) but I think that's our problem. Other users reported this also so maybe Gmail is the culprit for them also.
Really nice feature!
Please forgive my ignorance, but how are function references superior to
type TPoint = record X : double; Y : double; end; TDistanceFunc = function(p, q: TPoint): double;
Please forgive my ignorance, but how are function references superior to
type TPoint = record X : double; Y : double; end; TDistanceFunc = function(p, q: TPoint): double;
To give a more practical example about this, with such a feature you can generalize partial function application which can be used to specialize functions:
program Project1; {$mode objfpc}{$H+} {$modeswitch functionreferences} {$modeswitch anonymousfunctions} uses SysUtils; type generic TBinaryProcedure<TParam1, TParam2> = reference to procedure(const A: TParam1; const B: TParam2); generic TUnaryProcedure<TParam1> = reference to procedure(const A: TParam1); generic function Partial<TParam1, TParam2>(Func: specialize TBinaryProcedure<TParam1, TParam2>; const AValue: TParam1): specialize TUnaryProcedure<TParam2>; begin Result := procedure(const AParam: TParam2) begin Func(AValue, AParam); end; end; procedure LogToFile(const AFile: THandle; const AMessage: String); var LogMessage: String; begin LogMessage := '[%s] %s%s'.Format([DateTimeToStr(Now), AMessage, LineEnding]); FileWrite(AFile, LogMessage[1], LogMessage.Length); end; var Log: specialize TUnaryProcedure<String>; fl: THandle; begin // Log to consone out Log := specialize Partial<THandle, String>(@LogToFile, StdOutputHandle); Log('Console Log'); // Log to console error Log := specialize Partial<THandle, String>(@LogToFile, StdErrorHandle); Log('Error Log'); // Log to file fl := FileOpen('log.txt', fmOpenWrite); Log := specialize Partial<THandle, String>(@LogToFile, fl); Log('File Log'); ReadLn; end.
Weird.This is the partial application pattern, that is used in function programming languages (https://wiki.haskell.org/Partial_application). You can see it as a generalization of OOP methods.
I suppose that is the result of the effort for achieving a partial specialization overcoming limitation of the current generics in FPC, considering this (https://forum.lazarus.freepascal.org/index.php/topic,45818.msg325801.html#msg325801) and this (https://forum.lazarus.freepascal.org/index.php/topic,58753.0.html).
I'm a big fan of the functional programming too and I'm seeing the anonymous functions handy for map/fold/filter on containers and also for async/await futures (combined with a STAX?) but I'm not so sure for the function references.Function references have a huge andvantage. So I am writing a lot of code that makes use of function pointers, for example STAX, but also my iterators library (https://github.com/Warfley/ObjPasUtils/tree/master/src/iterators), and because I don't want to restrict the user to only one kind of function pointer, I need to define everything multiple times. Look at my functypes unit (https://github.com/Warfley/ObjPasUtils/blob/master/src/functypes/functypes.pas):
Maybe they're good for replacing the current method delegates, but that would break the LCL backward compatibility, i.e. it would not happen.
I see. Not familiar with Haskell but with the scheme language (https://en.wikipedia.org/wiki/Scheme_(programming_language)) where the same pattern is used to its fullest.Weird.This is the partial application pattern, that is used in function programming languages (https://wiki.haskell.org/Partial_application).
I suppose that is the result of the effort for achieving a partial specialization overcoming limitation of the current generics in FPC, considering this (https://forum.lazarus.freepascal.org/index.php/topic,45818.msg325801.html#msg325801) and this (https://forum.lazarus.freepascal.org/index.php/topic,58753.0.html).
*snip*
*snip*I don't see it as a generalization but as an alternative way to bind code to a context. I'll admit that in the latter you'll have an internally managed context, yes.
So this is basically the generalization of OOP methods. And as such it allows to give really powerfull tools, because OOP methods are bound to classes (or objects) and inheritance. With partial application, the same principle can be extended to any type and any number of parameters.
*snip*
*snip*It reminds me of similar efforts in another language before the variadic templates were added.
Aside from that, what I find really interesting about this approach, this is possible with only very few lines of code (basically the whole logger core type, which would be some form of abstract class in OOP, is with all function definitions just 40 lines of code). OOP introduces a lot of boilerplate code. This on the other hand is very slim. So I could imagine using this for some rather small things, where previously I would have used classes with just 1 or 2 (virtual/overriden) functionsQuoteI'm a big fan of the functional programming too and I'm seeing the anonymous functions handy for map/fold/filter on containers and also for async/await futures (combined with a STAX?) but I'm not so sure for the function references.Function references have a huge andvantage. So I am writing a lot of code that makes use of function pointers, for example STAX, but also my iterators library (https://github.com/Warfley/ObjPasUtils/tree/master/src/iterators), and because I don't want to restrict the user to only one kind of function pointer, I need to define everything multiple times. Look at my functypes unit (https://github.com/Warfley/ObjPasUtils/blob/master/src/functypes/functypes.pas):
Maybe they're good for replacing the current method delegates, but that would break the LCL backward compatibility, i.e. it would not happen.
*snip*
*snip*
60 lines or so, just to basically implement something that behaves as function references (just worse, because implicit specializations don't work transitively through implicit casts). And I have this for all kinds of functions and procedures from 0 to 5 parameters, It's 600 lines of code, just to emulate what is now provided at language level (and better).
*snip*
IMHO Such an undertaking to approximate a Pascal so close to a functional language is a bit too much. But it is not that I don't appreciate it from the academic point of view.I think that it is not necessarily trying to approximate pascal to a functional language, I think this is neither wise nor actually that possible (especially as the core concepts of functional languages, algebraic type system, fully expression based programs and side effect free programming, are something that must be supported on the very core of the language).