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

Paul Biggar <paul.biggar@gmail.com>
Mon, 31 Aug 2009 09:43:04 +0100

          From comp.compilers

Related articles
[5 earlier articles]
Re: Languages with well-integrated Foreign Function Interface to learn uninverted@lavabit.com (Nathan Seese) (2009-07-22)
Re: Languages with well-integrated Foreign Function Interface to learn gene.ressler@gmail.com (Gene) (2009-07-22)
Re: Languages with well-integrated Foreign Function Interface to learn dot@dotat.at (Tony Finch) (2009-07-26)
Re: Languages with well-integrated Foreign Function Interface to learn paul.biggar@gmail.com (Paul Biggar) (2009-07-28)
Re: Languages with well-integrated Foreign Function Interface to learn cr88192@hotmail.com (BGB / cr88192) (2009-08-24)
Re: Languages with well-integrated Foreign Function Interface to learn cr88192@hotmail.com (BGB / cr88192) (2009-08-30)
Re: Languages with well-integrated Foreign Function Interface to learn paul.biggar@gmail.com (Paul Biggar) (2009-08-31)
Re: Languages with well-integrated Foreign Function Interface to learn cr88192@hotmail.com (BGB / cr88192) (2009-08-31)
Re: Languages with well-integrated Foreign Function Interface to learn DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-09-02)
Re: Languages with well-integrated Foreign Function Interface to learn paul.biggar@gmail.com (Paul Biggar) (2009-09-02)
Re: Languages with well-integrated Foreign Function Interface to learn cr88192@hotmail.com (BGB) (2009-09-02)
Re: Languages with well-integrated Foreign Function Interface to learn paul.biggar@gmail.com (Paul Biggar) (2009-09-03)
Re: Languages with well-integrated Foreign Function Interface to learn cr88192@hotmail.com (BGB / cr88192) (2009-09-03)
[1 later articles]
| List of all articles for this month |

From: Paul Biggar <paul.biggar@gmail.com>
Newsgroups: comp.compilers
Date: Mon, 31 Aug 2009 09:43:04 +0100
Organization: Compilers Central
References: 09-07-074 09-07-095 09-07-105 09-08-050
Keywords: code, interpreter

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



Post a followup to this message

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