Re: Languages with well-integrated Foreign Function Interface to learn from?

On Sun, Aug 30, 2009 at 10:37 PM, BGB / cr88192 <cr88192@hotmail.com> wrote:
> > In my opinion, the best approach is to provide a
> > domain-specific-language which allows libraries to call C functions
> > directly, along with a data type to wrap void-pointers. This is
> > similar to Cython/pyrex, which I consider the current best-of-breed
> > for scripting language FFIs.
> >
>
> I once did this (long ago) to allow one of my languages (in this case,
> Scheme based), to interface with C. the cost was, however, that it was
> limited to statically compiled code, and had all sorts of integration issues
> with the interpreted version (for example, they could not directly share
> binding environments, ...).


For scripting languages, these are all existing problems in their
FFIs. The DLS approach I suggested would be a simple portable
replacement for the current C APIs, and would (intentionally) support
only statically compiled code. The integration with the interpreted
environment would be no worse than currently exists.




> more recently, my project has taken a very different approach:
> both the VM and native code are C.
<snip />
> however, all this effort does have a payoff:
> plain C to plain C integration.


If I understand you correctly, it seems that this interface wouldn't
be portable to other VMs, and that the standard libraries could not be
shared with another implementation which did not use a C virtual
machine?




> but, this does bring up another "generic" option: VMs can generally
> go and implement JNI as their FFI (even if the VM has little to do
> with the JVM), since one can at least pretend that JNI is a "sort
> of" standardized C-side FFI...


(I think) I don't like this idea, since it requires a reimplementation
of the same language to abide by some design principles of the
original implementation. In the approach I outlined above, the only
requirement is some way to statically link to C libraries, which I
believe to be as portable as is possible.




Paul
--
Paul Biggar
paul.biggar@gmail.com

Return to the comp.compilers page.
Search the comp.compilers archives again.