VM-level FFI architecture

[hawkw]

I'd love for the VM to contain a native foreign-function interface. Ideally, it should be possible to link in and execute functions from arbitrary compiled native C code, but there should definitely at least be a way to access core C library functions.

[hawkw]

I don't know very much about how a foreign-function interface works - this is an advanced topic we weren't able to cover in CMPSC420. Hopefully @janyljumadinova can offer some advice.

[hawkw]

Here's some documentation on C FFI in Rust. Might be helpful.

[hawkw]

The potential issue with providing low-level core OS functionality through hooks into libc rather than through hand-rolled fake syscalls on the VM (which seems like the other option here) is that a lot of the C standard library functions return C stuff. Currently, the VM has no idea what to do with a pointer or a struct, and it's likely that any Scheme programs that want to use FFI would have the same problem.

The options at this point are either to add VM instructions for working with Weird C Things directly, which breaks compatibility with other Scheme implementations (which is problematic if I want to claim to be 100% R⁶RS-compliant and if I want to implement my standard library by compiling the standard lib from some other Scheme implementation (as discussed in #16)); or, to give the FFI the ability to somehow munge Weird C Things into something the VM understands (i.e. breaking apart a struct into a list or what have you).

The main drawback of the second approach is that some C things lose semantic meaning if destructured - if I turn a pointer into a number, I now just have a weird number, while if I go get whatever it points to and put it on the VM stack, I no longer have the thing that the C library I'm talking to thinks that I have. There's also the issue that there would have to be some way to un-munge Weird C Things back into their original form for when I want to send them back to other C functions; which means that there would be a need to ensure anything mangled into a Seax-friendly form would have to be demangled deterministically into the same thing. This could be tricky.

Neither of these options are exactly good, and I still have to weigh the entire idea of providing core OS functions via FFI vs. making my own "fake syscalls" on the VM (which is what I believe Java does essentially). Hmm.

I'll have to think about this (and probably do more research).