R3-Alpha never had an FFI interface. So Shixin had to add one, and it was one of the first things he did.
We were all new to the R3-Alpha codebase at that time. And there wasn't a very obvious way to add such a feature, without hacking a lot of code into the core. New data structures were given to the GC, and all kinds of strange hooks needed to be added in the invocation of functions. There was no map for how to do it or way of judging right from wrong. So brittle things were tacked in everywhere.
Trying to break out the FFI into its own separate codebase motivated the design of the "dispatcher-based" actions we know today...where a single ACTION! datatype can provide the interface for any kind of function that one wanted. The methods of putting action description information into a "details" array also strongly shaped the system.
It's pretty accurate to say that the complexity of the FFI and its invasive reach meant that the design had to improve enough that the core could be insulated from it. It was basically the first "extension", and a particularly pathological case.
But the FFI is Not a Priority At The Moment
Several reasons:
-
Mixing a GC-based language with unmanaged code through FFI is notoriously brittle. Several of the techniques used in the FFI interface--such as giving out raw pointers to BINARY! or TEXT! data--were accidents waiting to happen.
-
libRebol has gotten very easy to use. Writing an extension with libRebol and linking it to a C library is generally a much cleaner way to make sure you're using the library correctly. It has the downside of needing to compile the extension, but the plus side of then being able to step through the bridging code with a debugger...as well as use things like address sanitizer.
-
Atronix is not doing new Rebol-oriented development at this time. The main reason it existed was their interests, and without that interest I can't afford to maintain it along with everything else.
Not Worrying About The FFI Will Help Rewriting Rebmake
Beyond being the most pathological extension code, the FFI was some of the most pathological build code. There were crazy build dependencies for 32-bit Windows cross compilation from Linux that were a total nightmare.
Being able to write and test Rebmake without that will ease that load.
The Code Won't Be Lost
If I were to approach the FFI today, I would do so much more from the idea that the natives exposed by the C had the sole job of exposing the libffi low-level functionality. All the higher-level analysis of the structures would be done in usermode code.
But the basic pattern is there if we needed it. Also, there's Shixin's video, which lays out the design and its motivations...so that gives a real leg up. Doing something a second time is always much easier.
In any case, the most important contribution of the FFI to the system design will stick around...that is to have an extension model that is capable of doing such complex things when they are needed. That framework is why we could do things like the TCC extension or the JavaScript extension. It's why we'll continue to be able to tackle similar problems without needing a major redesign.
So for now, we'll say the right way to interface with C libraries is as an extension. Solving problems in that domain with libRebol helps everything...both the web build and the desktop build.
UPDATE: Deed is done, separate repository (archived, read-only): github.com/metaeducation/rebol-ffi