Re: What's on my plate for Pika...

Matthew Dempsky <[email protected]> writes:

>   * Porting Pika's FFI - I haven't actually started this yet, but I
>     talked with Scott Miller (aka FoxFire; SISC developer) and he
>     expressed interest in having Pika available as a C FFI.  To quote:
>
>         "That would be fantastic.  I would almost certainly add it to
>         the official distribution.  [...]  We don't have a C FFI, so
>         it would be good to have until there is a decent FFI SRFI (50
>         doesn't yet count)."
>
>     I have zero familiarity with JNI so this will have to be held off
>     for a little while, but it might serve as a proof of concept and
>     add weight to Pika as a standard for a C FFI.
>
If I get you right, they want to use the Pika C interface (i.e. FFI)
for SISC. This would mean Pika and FFI can share C extensions, right?

>     I also wanted to look at Guile's FFI to see if it would be
>     possible to wrap easily, but because Pika and Guile both use the
>     scm_ prefix, there'd have to be some magical way of doing it.  For
>     example, both define scm_make_complex but in Guile it's
>     prototyped as:
>
>         extern SCM scm_make_complex (SCM real, SCM imag);
>
>     while in Pika we have:
>
>         extern t_scm_error scm_make_complex (t_scm_word * result,
>                                              t_scm_arena arena,
>                                              t_scm_word * a,
>                                              t_scm_word * b);
>
>     Maybe one of our resident Guile experts could give some insight?
>
[ Disclaimer: Being far from a Guile expert, I'm much lesser a Pika expert ;-) ]

I guess your intent is to re-use Guile extensions written in C for
Pika. The most significant problem I see is that Guile has no concept
of 'arenas'. So given a C function written for Guile's C interface
(and exposing a Guile-like prototype), you probably would have to
parse the function code and quite heavily munch it to spit out a
function that exposes a Pika-style prototype. 

Munching would at least include extending the orignal prototype with
an arena, doing likewise for all scm_*() calls in the function body
and deal with SCM vs. 't_scm_word *'. This seems not like an easy
undertaking. 

The other way round (i.e. making code written using the Pika-style FFI
usable from guile) should be easier (but probably not as useful, given
the amount of Guile C code vs. Pika C code).

Andy
-- 
Andreas Rottmann         | [email protected]      | 118634484@ICQ | [email protected]
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

It's *GNU*/Linux dammit!