>>>>> "Paul" == Paul Wilson <wilson@cs.utexas.edu> writes:
[Description of RScheme...]
Paul> Could you elaborate on this? Several issues:
Paul> - there's no C FFI in standard Scheme. Is there an emerging de
facto
Paul> standard? If not, what should a Scheme ffi look like, in its
broad
Paul> outlines? This is something that we've been meaning to look into
Paul> but never get around to. My impression of Guile's FFI is that
it's
Paul> not very impressive. (Too closely linked to the SCM
implementation
Paul> strategy.) The new C++ header reader for SCM (developed at the
Media
Paul> Lab to support X and 3D graphics standards) sounds more
interesting,
Paul> but I haven't looked into it.
Speaking as a user, a well documented C FFI is one of the most useful
things any Scheme implementation could have, especially one aiming to
be a Guile contender. Ideally, one that doesn't force the user to jump
through too many hoops. I've only looked at and played with STk's and
Elk's; both were pretty straightforward, although Elk's involved a few
more possible gotchas having to do with its more sophisticated GC.
>From what little I've seen, it appears that ALL Scheme FFIs are very
tightly linked to their own implementation strategy. A lot of the
problem comes from having to deal with GC of user defined types. I
wouldn't know enough to say whether you COULD have an (efficient)
implementation independent FFI (it would be nice but, I think,
unlikely to be widely adopted). I imagine most people just pick their
favorite one and stick to it.
I would very much like to see a documented C interface for RScheme;
from your description and from reading a little more about it in the
documentation, it sounds very exciting and promising.
>> What you have going for you is two things:
>> - higher-level code already carefully written.
>> This is actually a fair amount of code.
Paul> Yes. Donovan has done an amazing job.
(I thought Olin was referring to *scsh*'s higher-level code.)
|