RFC: ABI

[Qix-]

The generated Arua ABI is intended to be fully compatible with C.

For example, if the module tree (https://github.com/arua-lang/proposal/issues/4#issuecomment-223749408) looks like this:

mymodule/foo.ar:

use std.io

pub fn someFunction(foo i32, bar str, qux f128)
    io.out.println("#{foo} #{bar} #{qux}")

then the generated C symbol would look like

_mymodule_foo__someFunction___i32tstd_lang_str8__f128

• one _ separates the modules
• two __ separates types (incl. nested types)
• three ___ separates the symbol from the overload, denoting the start of a prototype
• two __ or the end of the symbol after three ___ indicates the end of a type in a prototype

Though this forces the constraint of not allowing underscores in type names, public identifiers or zone names. If we even forced that zone names could not contain upper case letters, this could be cleaned up even more:

_mymodule_foo__someFunction___i32tstdZlangZstr8_f128

Or something to that effect.

The goal here is to create a type naming system that can easily be compiled down to C-compatible symbols -- including the ability to patch in C code as Arua functions or method implementations through linking .ar -> .o and .c -> .o code together.

---

Another thing to think about is the ability to specify other languages as plugin bindings. This is something I'd like to see in a language personally.

#[lang=c++, symbol="some::namespace::SomeFunction"]
fn someFunction(foo i32, bar str)
    # do something; can be accessed from C++ as `some::namespace::SomeFunction(...)`

#[lang=java, symbol="com.arua.package.SomeFunction"]
fn someFunction(foo i32, bar str)
    # do something; implements the Java native function `com.arua.package.SomeFunction`

etc.