C API

For C/C++ based JavaScript interpreters, being able to interface easily with C libraries is a big win because of all of the available functionality. Each JavaScript interpreter has its own bridge to C, but if there is some common API (possibly exposed at the JavaScript level as in ctypes), then this will make it much easier to share work between interpreters.

Prior Art

• The JSAPI is the C API for the SpiderMonkey JavaScript engine https://developer.mozilla.org/En/SpiderMonkey/JSAPI_
• NSPR API Reference https://developer.mozilla.org/en/NSPR_API_Reference
• Ejscript http://www.ejscript.org/products/ejs/doc/api/native.html is a complete native API to create objects, classes and composite native types. It also supports loadable modules with backing native libraries.
• jsffi http://code.google.com/p/jslibs/wiki/jsffi is a module that allow you to call any symbol in a native module (dll/so).
• jsext "Including C functions" http://jsext.sourceforge.net/Including%20C%20functions.html
• js-ctypes https://wiki.mozilla.org/JSctypes is a foreign-function library for Mozilla’s privileged JavaScript. It provides C-compatible data types and allows JS code to call functions in shared libraries (dll, so, dylib) and implement callback functions.
• SpiderApe plugins http://spiderape.sourceforge.net/plugins/
• NSPR API Reference https://developer.mozilla.org/en/NSPR_API_Reference
• K7 http://github.com/sebastien/k7 Uses a system of C preprocessor macros to product cross-interpreter native modules.
• Flusspferd's C++ api http://docs.flusspferd.org/ provides a nicer (and slightly abstracted) C++ API to Spidermonkey
• GPSEE has an FFI-like layer which exposes generic native types/calls which are portable without JS-land changes between various UNIX and Linux platforms. Currently implemented for SpiderMonkey.

Papers

• C APIs in extension and extensible languages

The authors of Lua make a convincing argument for the advantages of the Lua 5 C API, which evolved considerably and incompatibly from Lua 1. They compare it with Python's API, Java's JNI API, and others. The main idea is that using a stack to communicate between Lua and C solves 2 "impedance mismatches" between Lua and C:

• Converting between the C type system and the Lua type system
• Manual memory management in C and automatic memory management in Lua (garbage collection). For example, the Python API is very concerned about the details of garbage collection, which Lua avoids. v8's API is also influenced strongly by its particular implementation of garbage collection.

Using the stack for communication also allows for a much smaller API, and they compare the sizes of the various APIs.