C-blocks

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: C-blocks

Free Pascal - General mailing list
Am 15.11.2018 um 03:59 schrieb 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.
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: C-blocks

Ryan Joseph


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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: C-blocks

Free Pascal - General mailing list
Am Do., 15. Nov. 2018, 08:39 hat Ryan Joseph <[hidden email]> geschrieben:


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

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


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 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: C-blocks

Ryan Joseph


> On Nov 15, 2018, at 5:09 PM, Sven Barth via fpc-pascal <[hidden email]> 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.

>
>
> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: C-blocks

Free Pascal - General mailing list
Am Do., 15. Nov. 2018, 15:01 hat Ryan Joseph <[hidden email]> geschrieben:
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 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: C-blocks

Ryan Joseph


> On Nov 15, 2018, at 11:30 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: C-blocks

Free Pascal - General mailing list
Am Fr., 16. Nov. 2018, 03:25 hat Ryan Joseph <[hidden email]> geschrieben:


> On Nov 15, 2018, at 11:30 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> 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 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: C-blocks

Ryan Joseph


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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: C-blocks

Free Pascal - General mailing list
Am Fr., 16. Nov. 2018, 12:57 hat Ryan Joseph <[hidden email]> geschrieben:


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

Yes. 


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 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal