Approaches to FFI
=================

Calling native code
-------------------

Being called/used/loaded from other languages as a library:

* Can generate header files for C
* Can generate unit files for FreePascal
* ...this approach can work for most native languages.

Calling into other languages:

* Require a SLUL module to be defined, that conforms to
  contracts expected by the SLUL language?
    - Requires extra work (but it doesn't hurt if there's some
      small resistence to adding interfaces to native code).
    - But interfaces can be better adapted to SLUL
      (and be safe, if the underlying code is safe)


Interpreting foreign code
-------------------------

There are at least 4 approaches here:

1. Load and interpret native code, e.g. x86.
2. Load and interpret WASM or some form other bytecode.
    - Would support a lot of languages.
    - Efficient to sandbox
    - Not memory safe within the program.
3. Parse some "compiler IR" (e.g. LLVM)
    - Can be somewhat memory safe (not just sandboxed).
4. Parse and interpret source code (e.g. JS, LISP or C).
    - Can be fully memory safe (not just sandboxed).
    - Otherwise, it's only feasible for somewhat small/simple
      languages, and even then it is probably much harder than
      running x86 or WASM.
    - Supporting JS would give access to a huge ecosystem.
5. Parse a custom, safe, IR.
    - Can be fully memory safe (not just sandboxed).

With option 1-4 there's a possiblity to use an existing compiler/emulator,
but of course, that means loading unsafe native code in itself, so it's not
risk free.

Option 2 (WASM) should be fairly simple to implement in SLUL itself.

For option 4, a JS or C interpreter in SLUL would be really cool. And a C
interpreter in SLUL could provide safety features that C compilers typically
don't provide (e.g. runtime type checks, strict aliasing checks, etc.).