[fpc-pascal] C-blocks

[Ryan Joseph]

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:

http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#Support_for_interfacing_with_C_blocks_functionality

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

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pasca

[Sven Barth via fpc-pascal]

Post by Ryan Joseph
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?
http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#Support_for_interfacing_with_C_blocks_functionality
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.

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
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pa

[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.

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

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi

[Sven Barth via fpc-pascal]

Post by Sven Barth via fpc-pascal

On Nov 15, 2018, at 1:27 PM, Sven Barth via fpc-pascal <
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?

Unlike you I'm in active contact with the developer and the last message
was only a few months ago.

Post by Sven Barth via fpc-pascal
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.

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

[Ryan Joseph]

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.

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.
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.

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

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fp

[Sven Barth via fpc-pascal]

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.

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

[Ryan Joseph]

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.

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

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.

[Sven Barth via fpc-pascal]

Post by Sven Barth via fpc-pascal

On Nov 15, 2018, at 11:30 PM, Sven Barth via fpc-pascal <
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.
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?

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

[Ryan Joseph]

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

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.

[Sven Barth via fpc-pascal]

Post by Sven Barth via fpc-pascal

On Nov 16, 2018, at 5:33 PM, Sven Barth via fpc-pascal <
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?

Yes.

Post by Sven Barth via fpc-pascal
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.

FPC could try that as well for such cases, but first and foremost it must
work correctly for the general, unoptimized case.

Regards,
Sven

Post by Sven Barth via fpc-pascal
<http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal>