A foreign function interface (FFI) is a mechanism by which a program written in one, usually an interpreted (scripted), programming language that can call routines or make use of services written or compiled in another one. FFI is often used in context where calls are made into binary dynamic-link library. Naming The term comes from the specification for Common Lisp, which explicitly refers to the programming language feature enabling for inter-language calls as such; the term is also often used officially by the Haskell, Rust, Python, and LuaJIT (Lua) interpreter and compiler documentations. Other languages use other terminology: the Ada programming language talks about "language bindings", while Java refers to its FFI as the JNI (Java Native Interface) or JNA (Java Native Access). Foreign function interface has become generic terminology for mechanisms which provide such services. Operation The primary function of a foreign function interface is to mate the semantics and calling conventions of one programming language (the host language, or the language which defines the FFI), with the semantics and conventions of another (the guest language). This process must also take into consideration the runtime environments and/or application binary interfaces of both. This can be done in several ways: Requiring that guest-language functions which are to be host-language callable be specified or implemented in a particular way, often using a compatibility library of some sort. Use of a tool to automatically "wrap" guest-language functions with appropriate glue code, which performs any necessary translation. Use of wrapper libraries Restricting the set of host language capabilities which can be used cross-language. For example, C++ functions called from C may not (in general) include reference parameters or throw exceptions. FFIs may be complicated by the following considerations: If one language supports garbage collection (GC) and the other does not; care must be taken that the non-GC language code does nothing to cause GC in the other to fail. In JNI, for example, C code which "holds on to" object references that it receives from Java must "register" this fact with the Java runtime environment (JRE); otherwise, Java may delete objects before C has finished with them. (The C code must also explicitly release its link to any such object once C has no further need of that object.) Complicated or non-trivial objects or datatypes may be difficult to map from one environment to another. It may not be possible for both languages