Re: on coding a portable R6RS package supporting Guile and its FFI

[ludo@gnu.org (Ludovic Courtès)]

Hi Marco,

Sorry for the delay.

Marco Maggi <marco.maggi-ipsu@poste.it> skribis:

> * Guile  does  not  come  with  the  very  simple  SRFI  78:
>   lightweight testing.  I had to include it[2][3].

Patches welcome.  :-)

> * It appears  that there  is no  facility to  handle "output
>   arguments" from  C functions; I  mean the cases where  a C
>   function accepts  as argument  a pointer to  variable that
>   will be  filled with  some computed value.   I am  using a
>   WITH-LOCAL-STORAGE[4]  macro  which  is  maybe  ugly,  but
>   works.

I typically roll my own allocation and dereference routines as well,
such as ‘make-int-pointer’ and ‘dereference-int’ at:

  http://git.savannah.gnu.org/cgit/libchop.git/tree/guile2/chop/internal.scm#n255

Perhaps adding them to (system foreign) would help?

>   Such  arguments are  common, and  represent a  nuisance to
>   handle.  Racket has a sophisticated interface, complicated
>   to use  when writing adapter code.   Something simpler but
>   built in would be useful (this is the sort of thing a user
>   does  not want  to think  about: it  should be  an already
>   solved problem).

I realize it would be good to have facilities already available for
this.

However, I’m not familiar with Racket’s FFI, and it’s not clear to me
what a good generic API would be.

For instance, one could imagine a layer on top of ‘pointer->procedure’
that would allow to specify whether pointer arguments really are output
arguments.  But then, you’d also have to allow programmers to tell how
output arguments are to be allocated (“pointerless” or not, ‘malloc’,
etc.), who owns them, what their life cycle is, etc.

All in all, it’s always seemed easier to me to do that manually, with
helpers specifically adapted to the C library I write bindings for.

WDYT?

> * Whenever  a callout  to C  accepts a  pointer argument:  a
>   bytevector argument  is rejected.   Is this not  a useless
>   complication?
>
>   One   can    work   around   it   by    explicitly   using
>   BYTEVECTOR->POINTER, so everything is ready in Guile.  The
>   other  Scheme   implementations  using   a  non-compacting
>   garbage collector already support  this feature and I find
>   it truly convenient.

Well, the ‘pointer’ type is useful, because it’s inherently a more
low-level representation than bytevectors.

That said, the FFI call could implicitly convert bytevectors to
pointers.  However, I generally prefer avoiding implicit type
conversions like these, for clarify.

Thoughts?

> * There are no raw memory  getters and setters[5]?

There’s only ‘dereference-pointer’ now, but I agree we could add more of
these, as well as pointer arithmetic operators.

> * The limit of  10 arguments for callouts to  C is annoying.
>   It forced me  to exclude some SOFA  functions resulting in
>   amputated Guile support.

Agreed.

Would you like to propose a patch in some of these areas?

Thanks for your feedback,
Ludo’.