Mailing lists / fpc-pascal / 2018-11
10 messages · 2 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Can c-blocks support Jonas added for Cocoa support be extended to other platforms or is this stuck with OS X? It uses a runtime library by Apple but is it possible to replace this with a custom Pascal implementation?
Somes notes:
In the compiler sources is the blockrtl.pp file which has the interface to the library, a mere 4 functions it looks like. Jonas did lots of work on this so it would be a shame if it was tied to OS X forever.
Regards,
Ryan Joseph
They are only useful when interacting with the external runtime. On other OSes nothing would support them thus there is no use for them. Additionally this requires extensive runtime, not to mention Objective C support.
There is even less sense in trying to port them as Object Pascal has anonymous functions which are already Work In Progress for FPC.
Regards,
Sven
On Nov 15, 2018, at 1:27 PM, Sven Barth via fpc-pascal wrote: They are only useful when interacting with the external runtime. On other OSes nothing would support them thus there is no use for them. Additionally this requires extensive runtime, not to mention Objective C support. There is even less sense in trying to port them as Object Pascal has anonymous functions which are already Work In Progress for FPC.
I see, that’s too bad. Anonymous functions appear to be dead as far as I can tell. In progress since 2012 I think?
Would it be permitted to add inline declarations of nested functions as a temporary replacement? They don’t capture state but at least they solve the issue of polluting namespace with named functions which you use in only one location. Better than nothing (since that’s what we’re realistically looking at) and no new complicated features.
Regards,
Ryan Joseph
Am Do., 15. Nov. 2018, 08:39 hat Ryan Joseph
geschrieben:
Unlike you I'm in active contact with the developer and the last message was only a few months ago.
No. This would conflict with the work of Blaise. Also even if we'd add that now it would not make 3.2 as it would be a too invasive change. So the earliest release would be 3.4 and for that I plan to have the real thing integrated into trunk. Thus it would be wasted effort to add that now.
Regards,
Sven
On Nov 15, 2018, at 5:09 PM, Sven Barth via fpc-pascal wrote: Unlike you I'm in active contact with the developer and the last message was only a few months ago.
That’s good news then but I’m not going to hold my breath. Best of luck to the man.
I just went back and read some of old threads of where closure support is at and it was mentioned that closures (i.e. what Delphi is calling anonymous functions) are actually a pretty heavy weight concept and require a non-trivial amount of overheard. Looking at the c-blocks implementation Jonas did the and RTL behind it confirms this to me.
Given that, having a light-weight “anonymous nested function” (not a “reference to” closure) is actually a nice compliment and in fact 2 different things. As FPC’s current c-blocks support demonstrates, it has closure properties but NOT anonymous functions (yet), which are indeed 2 distance concepts. Seems to be both are good to have.
Regards,
Ryan Joseph
Am Do., 15. Nov. 2018, 15:01 hat Ryan Joseph
geschrieben:
No, too many ways to do the same thing don't make things easier, not to mention that everything needs to be maintained. So this gets a definite "no" from me.
Also the overhead for calling an anonymous function is only that for a virtual method call.
Regards,
Sven
Do you mean if the anonymous function has no state it’s only a single function call?
After reading old forum posts it sounded like this was going to be implemented by some reference counted structure which was allocated on the heap and even using interfaces perhaps. Depending on how this is implemented it may not be possible to prevent them from capturing state if the anonymous function accesses variables in the parent scope.
How much of that is accurate?
Regards,
Ryan Joseph
Am Fr., 16. Nov. 2018, 03:25 hat Ryan Joseph
geschrieben:
When a function contains at least one anonymous function then a capture object is created which is shared by all anonymous functions in the function and also all captured local variables are moved there. If there is no variable to capture the capture object is nevertheless created. The call of an anonymous function is then always a virtual method call trough the interface VMT of the anonymous function into the capture object. So if you call an anonymous function multiple times you only have the overhead of the virtual method call, but only once the impact for creating the capture object (which might happen in different locations anyway if you pass an anonymous function outside of its declared scope).
Regards,
Sven
On Nov 16, 2018, at 5:33 PM, Sven Barth via fpc-pascal wrote: When a function contains at least one anonymous function then a capture object is created which is shared by all anonymous functions in the function and also all captured local variables are moved there. If there is no variable to capture the capture object is nevertheless created.
But is it an object on the heap with reference counting?
I read a number of articles on Lambda support in c++ and they seem to think in *some* instances the compiler can inline the lambda and see no speed penalty but they depends on it not being passed outside of the declaring scope. c++ may get away with this because you need to manually request captured variables.
Regards,
Ryan Joseph
Am Fr., 16. Nov. 2018, 12:57 hat Ryan Joseph
geschrieben:
Yes.
FPC could try that as well for such cases, but first and foremost it must work correctly for the general, unoptimized case.
Regards,
Sven