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

"Paul Biggar" <paul.biggar@gmail.com> wrote in message
> 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.


ok.


as can be noted, dynamic code generation allows dynamic interfacing as well
(grab a DLL and plug into it), but has a complexity cost...




>> 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?


another VM could use a similar strategy, but granted, to use plain C<->C
interfacing, the VM in question would need to be able to support C.


the great problem is that this quickly rules out most simple /
language-specific VMs...


basically, to handle both a dynamic language, and C, the VM would need a
similar level of complexity to that of .NET ...




another possibility would be to have several interconnected, but different,
VMs:
one which did C, and another which did the dynamic language;
then the main cost is the effort required to hook these together.


note:
just running bytecoded C will not buy anything, as one will need much of the
same types of metadata which is often available only to the compiler (AKA:
lots of very specific info about the typesystem, memory and stack layout,
...).


so, the C compiler would essentially serve several purposes:
A, to compile C;
B, to mine lots of information about pretty much everything visible at this
point.


with B, it is often sufficient just to try to "compile" a bunch of headers.


note that gathering, managing, and processing all this data, is its own set
of challenges...






but, at this point, one finds they can glue damn near anything to
anything...


for example, it would not be out of the question to glue C, for example, to
a fully textual set of interfaces and data representations. I had actually
considered something for this recently.


I can already more-or-less glue dynamic typing to C-style data
representations, ...




thus, my ideas for how to do JS in my present framework...
if done well, JS "should" be able to achieve close to 1:1 performance with C
(if compiled to statically-typed native code via lots of internal
trickery...).


however, a plain dynamically-typed version is also possible, but will likely
be a little slower.




>
>> 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.
>


JNI allows representing a lot more, and there are a lot of JVM-based
libraries which use it.
this only requires then that the VM be able to fake a JVM-like model (at
least for the external interface).


granted, this would be a little more awkward for dynamically-typed VM's, ...

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