Arc Forumnew | comments | leaders | submitlogin
FFI : a suggestion
8 points by sacado 6142 days ago | 6 comments
I currently ran in the need for an Arc FFI. I started to develop something useful for me. How do you feel the following ?

Imagine you've got a matrix.so offering the following C functions :

  typedef double * * matrix;

  matrix zeros (int lines, int cols);
  double get (matrix m, int line, int col);
  void set (matrix m, int line, int col, double value);
  matrix multiply (matrix a, matrix b);
Now, you want to use it in Arc, this way :

   (= m (zeros 3 3))
   (= n (mul m m))
   (set n 1 1 (+ (get n 1 1) 1.0))
   (prn:get n 1 1)
   -> 1.0
To do so, what about the following declaration before the Arc code above :

   (loadffi "matrix"
      (ctype mat (cptr (cptr cdouble)))

      (cdef set "set" void (mat cint cint cdouble))
      (cdef get "get" cdouble (mat cint cint))
      (cdef zeros "zeros" mat (cint cint))
      (cdef mul "multiply" mat (mat mat)))
The macro loadffi loads the "first-arg" file (appending .so or .dll depending on the OS), then lets the user describe types and functions he wants to "import" : cdef lets him define the Arc name, the foreign name, the return type (or void) and a list of arg-types. A few primitive C types are imported (int, short, long, float, double, char), plus the possibility to do typedefs, to express pointers and structs.

All of this is then dealt by mzscheme's FFI, and the rest can be defined directly within Arc.



5 points by treef 6142 days ago | link

This is cool and quite simple. But we don't just want ffi to native libs but also jvm and .net monstrosities. Since Arc is such a web2.0 language maybe some thing like a client server arch for ffi as in each language has a "ffi-server" like native-c, .net, java, python, perl ... arc connect to it via TCP and calls functions and gets data back. This could be optimized further and I think facebook has some thing like this (link any one?).

What you describe is very standard way to do a ffi - am trying to think out of the box, can I get any help?

-----

4 points by kens1 6139 days ago | link

Client-server sounds more like RPC than FFI. That leads to SOAP and WSDL, or XML-RPC if you want something lighter weight.

The biggest problem I see with implementing FFI through a server is it's very expensive if the server needs lots of the client state. For instance, suppose you implement matrix determinant in C for speed. With client-server, you'd need to copy the whole matrix across the connection; with local FFI, the C code can access the matrix directly.

-----

1 point by sacado 6139 days ago | link

Well, the client-server stuff can easily be done through sockets and a dedicated protocol on the native-process side. There are many such protocols, but this is not what I am after. I need ease of use (and, for other cases, speed).

Very standard, I know, but (as for now) I just want to use POSIX functions for a system utility. Picking in a .so file is just what I need. I don't want to start a server process, secure it (we're talking about functions manipulating my system and available to others through the net) and then communicate with it.

As for JVM and .Net, I totally agree with you. When I'll have something working, doing (for example) a JNI wrapper should be easy.

-----

3 points by cng 6142 days ago | link

Pyrex (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/) is a pretty interesting project to look at in this regard. It's not an ffi per se, but allows one to write C extension modules in a Python-like language, mixing Python and C datatypes freely. It would definitely be useful if Arc was capable of something like this, as it would make the language useful for numerical codes (my interest), system-level programming, etc.

-----

2 points by treef 6141 days ago | link

There is plenty of scheme to c compilers. I would think that one could compile arc to c and have option to go lower level and code c like constructs in arc.

I much prefer pypy rpython approach though it uses rtype (like ctype) to ffi to c most of the time but during complication of rpython to c the rtypes get replace completely. I think pyrex is a bit of a dead end.

-----

1 point by sacado 6139 days ago | link

I love Pyrex too. However, that means making (and maintaining) another compiler that should be compatible with Arc and still allow the extension features. That's a problem with Pypy, actually. You can't use any Python code in it, and it is quite restrictive in some cases.

However, you're quite right as I took the names cdef, cint, etc. from Pyrex.

-----