FFI supports callbacks

FFI supports callbacks

[Ludovic Courtès]

Happy Friday Guilers!

I'm pleased to announce that (system foreign) supports callbacks via the
new ‘procedure->pointer’:

  http://git.sv.gnu.org/cgit/guile.git/commit/?id=33186356668fe7697a8f2692660aaff69178d720

The function is similar to ‘make-foreign-function’ but does things the
other way around.

How do you like it?

Besides, I’m planning to push a 1.9.12 tarball tomorrow Saturday, after
updating NEWS.

Thanks,
Ludo’.

Re: FFI supports callbacks

[Andy Wingo]

Hi!

On Fri 03 Sep 2010 07:30, ludo@gnu.org (Ludovic Courtès) writes:

> I'm pleased to announce that (system foreign) supports callbacks via the
> new ‘procedure->pointer’:
>
> How do you like it?

Ludovic, that is breathtakingly great. My heart went aflutter looking at
the f-callback-1 test :-))

Only two thoughts:

 1) Do we need to trampoline through a scm_with_guile in the callback
    stub?

 2) Your commit has some tabs in it ;)

Cheers,

A
-- 
http://wingolog.org/

Re: FFI supports callbacks

[Ludovic Courtès]

Hello!

Andy Wingo <wingo@pobox.com> writes:

> On Fri 03 Sep 2010 07:30, ludo@gnu.org (Ludovic Courtès) writes:
>
>> I'm pleased to announce that (system foreign) supports callbacks via the
>> new ‘procedure->pointer’:
>>
>> How do you like it?
>
> Ludovic, that is breathtakingly great. My heart went aflutter looking at
> the f-callback-1 test :-))

That’s the least I could expect.   :-)

> Only two thoughts:
>
>  1) Do we need to trampoline through a scm_with_guile in the callback
>     stub?

Nooo, not necessarily, ‘scm_without_guile’ is old-fashioned.  Quoting
the fine manual:

     Starting from Guile 2.0, blocked threads no longer hinder garbage
  collection.  Thus, the functions below are not needed anymore.  They can
  still be used to inform the GC that a thread is about to block, giving
  it a (small) optimization opportunity for "stop the world" garbage
  collections, should they occur while the thread is blocked.

:-)

>  2) Your commit has some tabs in it ;)

Oh?  But not in Scheme files hopefully?

BTW, while we’re at it, how about make-foreign-function => pointer->procedure?
Sounds like the ultimate rename to me.

Thanks,
Ludo’.

Re: FFI supports callbacks

[Ludovic Courtès]

Hi there!

ludo@gnu.org (Ludovic Courtès) writes:

> BTW, while we’re at it, how about make-foreign-function => pointer->procedure?

We briefly discussed this on IRC.  One issue with the
‘pointer->procedure’ name is that ‘->’ procedures are most of the time
one-argument procedures, whereas ‘make-foreign-function’ has 3 mandatory
arguments.

However, it occurred to me that what confuses me most about
‘make-foreign-function’ is that it actually makes a Scheme procedure out
of a foreign function.

Conversely, ‘procedure->pointer’ really makes a foreign function out of
a Scheme procedure.

In addition, I like the idea of having names that show the symmetry of
these two procedures.

So, what do you think?  :-)

(I’m also open to different names that aren’t confusing and show the
symmetry.)

Thanks,
Ludo’.

Re: FFI supports callbacks

[Jose A. Ortega Ruiz]

On Sun, Sep 05 2010, Ludovic Courtès wrote:

> Hi there!
>
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> BTW, while we’re at it, how about make-foreign-function => pointer->procedure?
>
> We briefly discussed this on IRC.  One issue with the
> ‘pointer->procedure’ name is that ‘->’ procedures are most of the time
> one-argument procedures, whereas ‘make-foreign-function’ has 3 mandatory
> arguments.
>
> However, it occurred to me that what confuses me most about
> ‘make-foreign-function’ is that it actually makes a Scheme procedure out
> of a foreign function.
>
> Conversely, ‘procedure->pointer’ really makes a foreign function out of
> a Scheme procedure.
>
> In addition, I like the idea of having names that show the symmetry of
> these two procedures.
>
> So, what do you think?  :-)
>
> (I’m also open to different names that aren’t confusing and show the
> symmetry.)

import-foreign-function
export-foreign-function / export-to-foreign-function

procedure-from-foreign-function / foreign-function-to-procedure
procedure-to-foreign-function / foreign-function-from-procedure

procedure-from-foreign / foreign-to-procedure
procedure-to-foreign / foreign-from-procedure

at any rate, i find "pointer" not clear enough.

jao
-- 
Simplicity does not precede complexity, but follows it.
  - Alan Perlis, Epigrams in Programing

Re: FFI supports callbacks

[Andy Wingo]

On Mon 06 Sep 2010 00:23, "Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> procedure-from-foreign-function / foreign-function-to-procedure
> procedure-to-foreign-function / foreign-function-from-procedure
>
> procedure-from-foreign / foreign-to-procedure
> procedure-to-foreign / foreign-from-procedure

I don't think anything is gained by writing "from" or "to"; "->" is
indeed pronounced "too".

> at any rate, i find "pointer" not clear enough.

Agreed, though at least it is consistent. The subject does not lend
itself to a natural clarity.

Also consider that this is a low-level interface; presumably people
should be programming with some sort of `define-c-wrapper' macro that
presents a nicer interface.

Andy
-- 
http://wingolog.org/

Re: FFI supports callbacks

[Jose A. Ortega Ruiz]

On Mon, Sep 06 2010, Andy Wingo wrote:


[...]

> Also consider that this is a low-level interface; presumably people
> should be programming with some sort of `define-c-wrapper' macro that
> presents a nicer interface.

Is anyone working on this? I happen to quite like the design presented
in the paper "The Layers of Larceny's design":

<http://www.ccs.neu.edu/home/pnkfelix/Published/klock-ffi-schemeworkshop-2008.html>

I wouldn't be surprised if actual code could be lifted from Larceny's
implementation.

jao
-- 
The most important discoveries will provide answers to questions that we do
not yet know how to ask and will concern objects we have not yet imagined.
 -John N. Bahcall, astrophysicist (1935-2005)

Re: FFI supports callbacks

[Tristan Colgate]

A new swig flavour to support guile's ffi would be really nice too.
I've been building up patches to update the regular guile support but
might take a look at this as an alternative.

On 7 September 2010 01:30, Jose A. Ortega Ruiz <jao@gnu.org> wrote:
> On Mon, Sep 06 2010, Andy Wingo wrote:
>
>
> [...]
>
>> Also consider that this is a low-level interface; presumably people
>> should be programming with some sort of `define-c-wrapper' macro that
>> presents a nicer interface.
>
> Is anyone working on this? I happen to quite like the design presented
> in the paper "The Layers of Larceny's design":
>
> <http://www.ccs.neu.edu/home/pnkfelix/Published/klock-ffi-schemeworkshop-2008.html>
>
> I wouldn't be surprised if actual code could be lifted from Larceny's
> implementation.
>
> jao
> --
> The most important discoveries will provide answers to questions that we do
> not yet know how to ask and will concern objects we have not yet imagined.
>  -John N. Bahcall, astrophysicist (1935-2005)
>
>
>



-- 
Tristan Colgate-McFarlane
----
  "You can get all your daily vitamins from 52 pints of guiness, and a
glass of milk"

Re: FFI supports callbacks

[Ludovic Courtès]

Hi!

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

>> Also consider that this is a low-level interface; presumably people
>> should be programming with some sort of `define-c-wrapper' macro that
>> presents a nicer interface.
>
> Is anyone working on this?

I’m not really working on this but I’m interested (I’ve been using
(system foreign) + custom macros so far.)

> I happen to quite like the design presented in the paper "The Layers
> of Larceny's design":
>
> <http://www.ccs.neu.edu/home/pnkfelix/Published/klock-ffi-schemeworkshop-2008.html>

Sounds cool.

There’s also a C parser in Bigloo (“Cigloo”), which could be reused to
extract information from C headers.

Thanks,
Ludo’.

Re: FFI supports callbacks

[Andy Wingo]

On Tue 07 Sep 2010 02:30, "Jose A. Ortega Ruiz" <jao@gnu.org> writes:

>> Also consider that this is a low-level interface; presumably people
>> should be programming with some sort of `define-c-wrapper' macro that
>> presents a nicer interface.
>
> Is anyone working on this? I happen to quite like the design presented
> in the paper "The Layers of Larceny's design":

Not me. I was hoping someone else would get around to it before I would
:)

> <http://www.ccs.neu.edu/home/pnkfelix/Published/klock-ffi-schemeworkshop-2008.html>

Very cool trick with running the C compiler at macroexpansion time!

Andy
-- 
http://wingolog.org/

Re: FFI supports callbacks

[Ludovic Courtès]

Hi!

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> On Sun, Sep 05 2010, Ludovic Courtès wrote:
>
>> Hi there!
>>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> BTW, while we’re at it, how about make-foreign-function => pointer->procedure?
>>
>> We briefly discussed this on IRC.  One issue with the
>> ‘pointer->procedure’ name is that ‘->’ procedures are most of the time
>> one-argument procedures, whereas ‘make-foreign-function’ has 3 mandatory
>> arguments.
>>
>> However, it occurred to me that what confuses me most about
>> ‘make-foreign-function’ is that it actually makes a Scheme procedure out
>> of a foreign function.
>>
>> Conversely, ‘procedure->pointer’ really makes a foreign function out of
>> a Scheme procedure.
>>
>> In addition, I like the idea of having names that show the symmetry of
>> these two procedures.
>>
>> So, what do you think?  :-)
>>
>> (I’m also open to different names that aren’t confusing and show the
>> symmetry.)
>
> import-foreign-function
> export-foreign-function / export-to-foreign-function
>
> procedure-from-foreign-function / foreign-function-to-procedure
> procedure-to-foreign-function / foreign-function-from-procedure

OK.  (Slightly to verbose to my taste.)

> procedure-from-foreign / foreign-to-procedure
> procedure-to-foreign / foreign-from-procedure
>
> at any rate, i find "pointer" not clear enough.

Hmm but I find ‘foreign’ as a substantive hard to parse.  :-)

The object type in question is now called ‘pointer’ (it used to be
‘foreign’), hence the name.  “Pointer” is meant as a synonym for
‘void *’ ans pointer objects are untyped, which may be why it seems
“vague”.  But hey, the concept of pointing to the void *is* vague.
:-)

Thanks for the suggestions!

Ludo’.

Re: FFI supports callbacks

[Andy Wingo]

Greets,

On Sun 05 Sep 2010 17:10, ludo@gnu.org (Ludovic Courtès) writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> BTW, while we’re at it, how about make-foreign-function => pointer->procedure?
>
> We briefly discussed this on IRC.  One issue with the
> ‘pointer->procedure’ name is that ‘->’ procedures are most of the time
> one-argument procedures, whereas ‘make-foreign-function’ has 3 mandatory
> arguments.
>
> However, it occurred to me that what confuses me most about
> ‘make-foreign-function’ is that it actually makes a Scheme procedure out
> of a foreign function.
>
> Conversely, ‘procedure->pointer’ really makes a foreign function out of
> a Scheme procedure.
>
> In addition, I like the idea of having names that show the symmetry of
> these two procedures.
>
> So, what do you think?  :-)

I guess I'm OK with it. The new names do convey the types better to the
programmer. I'm hesitant regarding "pointer" though; the name is just so
general. I guess I prefer "machine-pointer" or something. But I would
also be OK with the change as you propose it.

Andy
-- 
http://wingolog.org/

Re: FFI supports callbacks

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> writes:

> On Sun 05 Sep 2010 17:10, ludo@gnu.org (Ludovic Courtès) writes:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> BTW, while we’re at it, how about make-foreign-function => pointer->procedure?
>>
>> We briefly discussed this on IRC.  One issue with the
>> ‘pointer->procedure’ name is that ‘->’ procedures are most of the time
>> one-argument procedures, whereas ‘make-foreign-function’ has 3 mandatory
>> arguments.
>>
>> However, it occurred to me that what confuses me most about
>> ‘make-foreign-function’ is that it actually makes a Scheme procedure out
>> of a foreign function.
>>
>> Conversely, ‘procedure->pointer’ really makes a foreign function out of
>> a Scheme procedure.
>>
>> In addition, I like the idea of having names that show the symmetry of
>> these two procedures.
>>
>> So, what do you think?  :-)
>
> I guess I'm OK with it. The new names do convey the types better to the
> programmer. I'm hesitant regarding "pointer" though; the name is just so
> general. I guess I prefer "machine-pointer" or something. But I would
> also be OK with the change as you propose it.

I committed the change yesterday.

Thanks,
Ludo’.