Re: [Pika-dev] What's on my plate for Pika...

[Andreas Rottmann]

Matthew Dempsky <address@hidden> writes:

>> 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).
>
> Actually, that is the goal.  Basically the idea is the same as it is
> for SISC -- to reinforce the idea that Pika's FFI is general enough to
> serve as a standardized C FFI for Scheme (or to identify areas where
> it needs correcting), it would be helpful to be able to say "Hey, look
> - you can write code to Pika's FFI and it can interface not only with
> Pika, but also [SISC, Guile, or whatever we can manage]."
>
That's a really nice goal! When Pika is major enough, I will certainly
consider porting g-wrap [0] to use the Pika FFI, iff that means it
will still work with Guile (and SISC, ...). This would open the
possibilty of getting the bindings stacked upon it (GTK+2, libgda,
GStreamer, ...) to work with three implementations instead of
one. That's a really promising perspective IMO.

[0] http://yi.org/rotty/GWrap.html

> I'm sure there's a good deal of code already written to specific
> implementation FFIs, but the long term plan (or my understanding of it
> at lesat) is to get this code ported to Pika so that any
> implementation can benefit from it.
>
I see.

> (Of course it would also be helpful to be able to automate a process
> of porting code using another implementation's FFI to Pika's, but we
> can worry about that later.  It will be hard to drive interest into
> porting code to Pika's FFI if we can't make that code still usable
> with the FFI they're currently using.)
>
Sure. One area where the Guile and Pika FFI's will differ big time is
error handling. From what I get out of the Pika notes, errors are
returned as return values, whereas Guile uses non-returning functions
(that longjmp to the handler). I would be interested how the "Plan"
for errors looks like; I didn't find much about it in the notes. I
think it might be a good idea to have a look at SRFI-35 and keep that
in the back of the head while designing the error handling mechanism.

Error/Exception handling and unifiying Guile and Pika FFI is an area
I'd be interested in getting my hands dirty; however, I don't quite
know where errors fit into the big picture/plan.

Rotty
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Packages should build-depend on what they should build-depend.