Foreign Function Interface

[sjmackenzie]

This is a continuation of #44 under an appropriately named issue.

Erlang in the past few years introduced NIFs.

I'm starting to think a better direction is to implement an equivalent of NIFs but for oz. This allows us implement functions in C++ rather than oz.

Take a look: http://www.erlang.org/doc/man/erl_nif.html

[sjrd]

IMO, the NIF equivalent in Oz are the builtin modules. Dynamically loaded libraries for the VM should be able to register new builtin modules. They can also obviously define new data types, and new interfaces. But what they should also be able to do is define new data types that implement existing interfaces (requires dynamic linking of interface calls).

With Yves, back then, we also thought that something very interesting would be to provide automatic binding with JVM classes, using a JVM as a symbiotic VM. Using a JVM as the basis for FFI (or whatever it's called) provides two main benefits:

• There are lots of existing libraries for the JVM. We could reuse them as is.
• JVMs are very efficient these days.

Since JVM classes are almost perfectly OO, it's possible to implement one unique, generic interface between Oz and JVM. We would need an encoding for static methods, but that's not very difficult.

[sjrd]

Btw, I'd love to see an Oz VM written with Truffle: http://medianetwork.oracle.com/video/player/1785432528001

[sjmackenzie]

This is the equivalent of an oz builtin in Erlang land (a BIF http://www.erlang.org/doc/man/erlang.html)

What I dislike about the builtin approach this is that a developer cannot easily create a builtin without compiling the mvm2 from scratch. A developer should easily be able to drop down into C/C++ and create a library without an mvm2 recompilation. Then in Oz one would interact with the C/C++ library just as one would interact with an oz port. Take a look at this quick example http://www.erlang.org/doc/man/erlang.html

As my main motivation is introducing DJB's NaCL encryption libraries and the Enlightenment Foundation Libraries which are C based. The correct way would be to implement a FFI which allows for a generic way of getting stuff into the mvm2.

JVM has massive throughput. It targets a client server architecture. Ie huge jvm server handling millions of clients. Fat Server - Thin Clients. The mvm2 fits into a different area, one of P2P. Each node handles it's own resources. This is a domain whereby the computation is spread out over the node graph. Therefore the mvm2 should specialize and dominate in this niche. Hence encryption for open internet, and EFL for native beautiful GUI support. Oz shouldn't try compete in the client server market, it'll fail miserably. As the world will have to move to a P2P direction, it is good to setup these systems early so that mvm2 is able to move in and take this domain.

Therefore supporting Java methods is not something that I'm looking at, though it might possible to create an abstraction to allow C++ libraries and a JVM libraries? Thus benefiting from a richer eco-system.

BTW sorry about that video I posted earlier (I removed it from the OP), it seemed to be mostly basho marketing, than actual NIF substance.

Truffle: wow... a rewriting inline cache. To me this looks more appealing implemented in mvm2, rather than implementing a JVM based Oz vm. I would love to see that!

[sjrd]

OK, I guess that makes sense.