External functions, foreign function interface.

[elucent]

Support the definition of functions with undefined bodies. These functions must have full type annotations, and represent external symbols that will be resolved at link time. This will allow Basil to interact with native libraries and substantially broaden the kinds of applications Basil can be used in.

In the current Basil runtime, code is JIT-compiled, so we'd need to create our own linker of sorts to find the implementations of these functions. For a start, we should consider just supporting shared objects, to avoid having to parse ELF files. We can consider full-on AOT compilation for a later issue.

[elucent]

Though it's become a little more indirect, FFI should definitely be achievable in the 1.0 release. There's a few methods we could employ to achieve this, which probably deserve independent issues if we pursue them:

• Jasmine objects currently support linking in arbitrary function pointers at runtime. We could extend Jasmine objects with support for shared libraries. At minimum, this should include the ability to load a dynamic symbol when JIT-compiling Basil code...more sophisticatedly, we should investigate embedding shared library linkage in relocatable ELF objects (how possible even is this?).
• There's tentative support for AOT-compilation of Basil code to relocatable ELF objects. We should more rigorously test this, support data and static sections in Jasmine objects, and potentially add a frontend in the Basil or Jasmine CLI to more easily link Basil objects into executables or shared libraries (using the system linker for now).

[dumblob]

This sounds awesome! This type of FFI would be a static/compile-time/AOT offering high performance.

In addition to that I'd also welcome support for runtime execution of Python ecosystem. As crazy as it sounds, I imagine it like PythonCall.jl (not to be confused with PyCall). I think this is the only way to get immediate support for anything one can think of in Basil without spending 10 years developing some new/shim/wrapper libraries which will anyway never fully catch up because big langs will be also 10 years ahead.

C/C++ libs are by far not enough for real-world apps. Therefore I'm suggesting this support of the biggest ecosystem in the world.